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© Block diagram editor system and method. 



© A block diagram editor system and method is 
implemented in a computer workstation that includes 
a CRT and a mouse, graphics and windowing soft- 
ware, and an external communications interface for 
^ftest instruments. The computer is programmed for 
constructing, interconnecting and displaying block 
O diagrams of functional elements on the CRT. From 
jj^prestored routines for each functional element, the 
softwave assembles and executes a program that 
emulates the functional operations of each element 
^jand transfers data from output from each element in 
turn to an input of a succeeding block, as deter- 
® mined by the block diagram configuration. The block 
Q. functions include signal generating and analysis 
UJ functions, and functions for control of various types 
of test instruments, which can be interactively con- 
trolled through the CRT and mouse. The computer 



converts desired outputs of the instruments into con- 
trol settings and receives, analyzes and displays 
data from the instruments. Blocks can also be 
grouped into macroblocks. 
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Figure 1. — Simple Application using Block Diagram Editor. 
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BLOCK DIAGRAM EDITOR SYSTEM AND METHOD FOR CONTROLLING ELECTRONIC INSTRUMENTS 



RELATED APPLICATION DATA 

This application is related to commonly-as- 
signed U.S. patent application Ser. No. 935,369 , 
filed on even date herewith by D. Stubbs, entitled 
SIGNAL VIEWING INSTRUMENTATION CON- 
TROL SYSTEM. 



BACKGROUND OF THE INVENTION 

The invention relates generally to a graphical 
user interface system and more particularly to a 
system and method for a user interactively to 
computer-control an electronic testing system. 

In a typical experiment or testing environment 
there is a device or object under test, a means to 
stimulate the device under test and a means to 
measure the response of the device to stimulation. 
The process of stimulus/response testing is typi- 
cally followed by an analysis phase to extract spe- 
cific information from the response measurement 

In a computer-based instrument environment, a 
host computer is connected to the stimulus and 
response instruments. This computer, commonly 
called the controller, controls the operation of the 
test instruments and can be used to perform the 
analysis of the response data. The most common 
interface for connecting the controller to the instru- 
ments is the GPIB (General Purpose Interface 
Buss) or IEEE 488 standard. 

The most common approach to control of this 
computer-based stimulus/response testing has 
been to write a program in BASIC, FORTRAN or 
other high-level programming language to control 
the instrumentation and, in a similar manner, to 
write a program to perform the response data ana- 
lysis. The instrument control programs convention- 
ally include subroutines, or drivers, which interpret 
the control expressions in the high-level language 
and convert them into the communication protocol 
required to control the instrument For certain in- 
struments, drivers may also report the state of the 
instrument such as the control settings and error 
status information, as well as the response data 
that an instrument may detect These drivers are 
essentially similar to the computer operating sys- 
tems used to communicate with peripheral devices, 
such as terminals, disk drives and magnetic tape 
drives. 

BASIC is typically the language of choic for 
test system developers and users, because it is 
easy to learn by novices and is interactive. Never- 
theless, the writing of control and analysis pro- 



grams can become quite tedious and the programs 
are often difficult to modify. The user must commu- 
nicate with the test instrumentation in terms of its 
conventional control settings, e.g. amount of verti- 
s cal offset vertical scale factor, etc. The user must 
understand not only how to control the test instru- 
ment but how to communicate the desired controls 
in the programming language. 

Many high-level languages have also been ex- 

10 tended to provide means for graphically displaying 
data returned from test instruments. The programs 
employ windowing modules or subroutines to con- 
vert acquired data. e.g„ digitized signals, from the 
coordinate system of the data, e.g., time vs. volt- 

75 age, into the coordinate system of the display 
device (CRT). With data transformed into display 
coordinates, graphing modules interpret various 
language commands and apply the commands to 
the display-coordinate data and produce instruc- 

20 tions in a form that the display device requires to 
render a graphical representation of the test data- 
High-level language elements, windowing mod- 
ules and graphing modules have been widely used 
to produce graphical representations of data stored 

25 in computer memory. They have also been used in 
conjunction with graphic input devices, e.g., a 
joystick, mouse, etc, which controls a display cur- 
sor, to interpret the cursor's screen location in 
terms of the coordinate system of the display data. 

30 This type of display system enables the user to 
display the stored data in different scales, but the 
resolution of the data displayed is limited to that 
which is stored. Zooming in on a portion of a 
waveform cannot add any more detail about the 

35 waveform than was originally stored. Also, the 
stored data is limited to the record length of data 
stored. Thus, zooming out beyond the dimensions 
of the stored data does not make more data avail- 
able. To remedy both of these problems requires 

40 the user to reprogram the test instrument to ac- 
quire a new set of data. 

In conventional manual operation of test instru- 
ments, the user operates the test instrument con- 
trols interactively In response to the graphical pre- 

45 sentation of the data. The operation of program- 
mable test instruments controlled by high-level pro- 
gramming languages, however, requires fore- 
thought and calculation. Thus, programmable test 
instruments are difficult to use in an interactive 

50 manner. The user can set goals in terms of the 
display data, but must transform these goals Into 
terms of test instrument settings in order to act If 
more than one instrument is being used, each must 
be set separately. Similarly, if the manner of analy- 
sis of the returned test data is to be modified, the 
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analysis routines must also b8 reprogrammed. All 
of this entails much complexity, and requires sub- 1 
stantial expertise, time and careful work to accom- 
plish successfully. 

Software systems are also known which enable 
a user to model and simulate systems on a com- 
puter and interactive display. An example of such a 
system is BLOSIM, a general purpose simulation 
program for sampled data systems described in 
D.G. Messerschmitt, "Blosim - a Block Simulator," 
Dept. of Electrical Engineering, Univ. of California - 
Berkeley (June 7, 1982). A BLOSIM user partitions 
a system to be simulated into smalt pieces im- 
plementing elementary parts of the system, each 
piece called a block, and provides a simulation 
program for each block. The user also provides a 
program that defines the topology of interconnec- 
tion of the blocks. BLOSIM then handles the details 
of the actual interconnection and execution of the 
blocks. BLOSIM was not designed to be used as a 
test instrument control program. Moreover, the to- 
pology of the blocks must be recompiled each time 
a change is made in the system under test Addi- 
tionally, application of BLOSIM to actual systems 
becomes very difficult as the topologies become 
increasingly complex. Hence, within the known 
state of the art, BLOSIM is not applicable to test 
instrumentation control. 

Accordingly, a need remains for an improved 
method and apparatus for controlling test instru- 
mentation and analyzing signals. 

SUMMARY OF THE INVENTION 

One object of the invention is to provide an 
improved method and means for controlling, 
through a computer workstation interface, a test 
instrumentation system. 

A second object of the invention is to provide a 
single channel of access to engineering, testing, 
analysis, research, etc. resources in a test system. 

Another object is to eliminate the need for test 
instrument front panel controls and displays by 
providing workstation-based control and thereby re- 
duce the cost of programmable test instruments. 

A further object is to minimize the time re- 
quired for a user to establish or modify test instru- 
ment settings. 

Yet another object is to enable a user to control 
a test system or to analyze signals in a manner to 
which the user is accustomed, including defining 
control or analysis in terms of operational goals. 

An additional object is to enable a user to 
control the compl xity of the user interface with 
t st instrumentation systems and analysis prob- 
lems. 

The invention provides a method and appara- 



tus for controlling .a test instrumentation system, or 
usable in oth r applications such as signal analysis, 
that enables a user to manipulate operation through 
a graphical interface based on block diagrams. The 

5 system includes a programmable computer having 
a memory, a processor, a graphical display means, 
and input means including user-operable means for 
selecting and positioning graphic data on the dis- 
play. Preferably, for controlling a physical system 

10 such as test instrumentation, the computer also 
includes an external communications means. The 
computer is programmed with software which en- 
ables the user interactively to edit and program a 
block diagram for execution by the computer. 

75 So programmed, the system includes block 
display means responsive to the user operable 
means for displaying a plurality of user selected 
blocks as graphical data on the display. The blocks 
include a first type of block having at least one 

20 output terminal and a second type of bbck having 
at least one input terminal, and can include blocks 
having both input and output terminals. Associated 
with each of the first type of blocks is a function 
instruction means executable by the processor for 

26 generating a first set of signal data in accordance 
with a predefined first function and providing the 
signal data at the output terminal of such block. 
Similarly, associated with each of the second type 
of blocks is a function instruction means executable 

30 by the processor for transforming an input signal 
data in accordance with a predefined second func- 
tion. The second type of block can include means 
for returning information derived from the trans- 
formed data to the user. A third type of block has 

35 both input and output terminals. Such blocks have 
an associated function instruction means that is 
executable by the processor for transforming the 
input signal data in accordance with a predefined 
third function and providing a transformed set of 

40 signal data on the output terminal. 

The system also includes interconnection dis- 
play means responsive to the user-operable means 
for displaying an interconnection between the var- 
ious types of blocks, connected from an output 

46 terminal of one block to an input terminal of an- 
other block as designated by the user. Associated 
with the displayed interconnection is a data flow 
means for transmitting the signal data from output 
to input terminal between the function instruction 

so means associated with each of the blocks between 
which the displayed interconnection is connected. 

The system includes means responsive to the 
input means for actuating the processor to execute 
each of the function instruction means in turn. 

55 Accordingly, a first set of signal data is g nerated 
in accordance with, the functions of each of the first 
type of blocks. This set of signal data is transmit- 
ted to the function instruction means of blocks of 
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the second type in accordance with the data flow 
paths defined by the interconnections. The signal 
data generated by the blocks of th first type is 
then transformed in accordance with the functions 
of the second type of blocks to produce a second 5 
set of signal data. 

The system can include means for actuating 
the graphical display means for graphically display* 
ing the second set of signal data. Transforming- 
type blocks, having both input and output termi- w 
nals, and their associated function instruction 
means, can be connected between blocks of the 
first and second type to perform intermediate trans- 
formations of the signal data. 

Preferably, the system includes a block storage 75 
means for storing a plurality of unique function 
instruction means, each in association with a pre- 
determined user-selectabie block. A means is pro- 
vided for the user to select by operation of the 
user-operable means and block display means, the 20 
stored function instruction means associated with a 
designated block. A means is also provided that is 
responsive to the user interconnecting the blocks 
on the display means for assembling the function 
instruction means for each designated block for 25 
execution by the processor in a sequence deter- 
mined by the direction of signal data transmission 
indicated by the interconnections. 

Two or more blocks of the first type can be 
connected by interconnections to a block of the 30 
second type and the system includes means for 
executing the selected function instruction means 
for each of the first type of block and outputting 
resultants of the signal data from each such block 
to the second block in substantially parallel opera- 35 
tion. Similarly, a block of the first type can be 
connected by interconnections to two or more 
blocks of the second type and the system includes 
means for executing the selected function instruc- 
tion means for the blocks of the second type or> 40 
the signal data transmitted by the data flow means 
for each interconnection from the first block. 

Many different kinds of blocks can be used in 
the system, the function of each being determined 
by the associated prestored function instruction 45 
means. Some blocks function to generate, trans- 
form or display data within the computer. Others 
function to control operation of physical apparatus, 
such as programmable test instruments, through 
the external communications interface. The function so 
instruction means of the latter type include means 
for generating commands to program settings of 
the instruments. A block and associated function 
means can be provided which, respectively, repre- 
sents and simulates the physical system in the ss 
block diagram, e.g., for comparing operation of a 
prototype devic with a design simulation of the 
device. 



The function instruction means can include on 
or more user-settable parameters responsive to 
user operation of the input means to modify the 
function thereof. Similarly, th function Instruction 
means for certain blocks, such as a digitizer, can 
be operated to produce or transform a two-dimen- 
sional signal with the graphic display means op- 
erable to display such signal as two-dimensional 
graphic data Preferably, a means is provided, 
which is responsive to operation of the user-op- 
erable means to select and position a feature of the 
displayed two-dimensional graphic data, for man- ^ 
ipulating the function instruction meains of such 
block to modify the function thereof. Such means 
correspondingly includes means for transforming 
the displayed feature from display coordinates into s 
terms of settings of the instrument to reset its 
parameters as the associated function instruction 
means are readied for execution. 

The preferred embodiment further includes 
means actuable by the user-operable means for 
the user to select and group the displayed blocks 
and their associated connections to form a macro- 
block executable as a unit by the processor. The 
block storage means can correspondingly include 
means for storing the macro-block for manipulation 
in same manner as blocks of the first, second and 
third type. Such means can further include means 
for storing any parameters associated with the 
blocks constituting a macro-block and enabling the 
user selectively to modify such parameters. A 
means is preferably provided for the user to nest 
macro-blocks within other macro-blocks. 

The invention enables a user to plan, decom- 
pose and carry out measures, experiments, signal 
analysis and other complex tasks, concentrating on 
the goals of the task at hand, by expressing the 
task in a way familiar to the typical user-a block 
diagram. It enables the user to program in the 
semantics of a given problem, with little or no 
interference from the syntax of programming lan- 
guage. By working with schematic concepts, the 
user's concentration is focused on the problem, the 
system is easier to use and learn and the cognitive 
burden is less. The system allows the user, in 
effect, to draw programs with predefined process- 
ing elements or blocks and interconnections. If a 
block diagram becomes too complex, the user can 
readily reduce its complexity by grouping several ^ 
blocks together and displaying them as a single, 
higher-level macro-block. 

_ In a preferred embodiment the user selects 
desired blocks from a menu displayed in one por- flf 
ti n of the graphic display, positions th selected 
blocks in an editing area, and interconnects the 
inputs and outputs of the blocks as desired to 
direct the data flows. The user may group blocks 
into macro-blocks to reduce visual complexity and 
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to prevent overflow of the editing area. The macro- 
blocks can then be added to the collection of 
predefined blocks. The user may also place non- 
executable "empty" blocks in the editing area and 
can subsequently refine them into collections of 
predefined blocks as the user's grasp of the prob- 
lem becomes more concrete. 

After having drawn a diagram that represents 
what the user intends to accomplish, the user can 
then execute the diagram. From the user's 
viewpoint the diagram is the program. The dia- 
gram also self-documents both the program and 
the particular experiment or analysis task that has 
been designed and executed. Preferably, the soft- 
ware is written in an object-oriented language, 
which facilitates the documentation and information 
presentation task by enabling a user to "look in- 
side" blocks at descending layers of complexity 
while leaving that complexity behind for ease of 
manipulation and editing of the block diagrams. 

The foregoing and other objects, features and 
advantages of the invention will become more 
readily apparent from the following detailed de- 
scription of a preferred embodiment which pro- 
ceeds with reference to the accompanying draw- 
ings. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an illustration of a graphical display 
screen showing a simple application of the block 
diagram editor system of the invention to a signal 
analysis problem. 

FIG. 2 shows the output information appear- 
ing on the display screen after executing the exam- 
ple of FIG. 1. 

FIG. 3 is a diagram of the software structure 
implementing the block diagram editor system of 
the invention. 

FIG. 3a is a diagram of the Block Editor 
Model -View-Controller relationships in the software 
structure of FIG.3, the dotted lines indicating de- 
pendency relationships. 

FIG. 3b is a diagram of the DisplayBlock 
-BlockParams - FormFillOut relationships in the 
software structure of FIG.3, each question/answer 
pair being one "HorizFilllnTheBlank." 

FIG. 3c is a diagram of the execution man- 
ager portion of the software structure of FIG. 3. 

FIG. 4 is a diagram illustrating an example of 
operation of the execution manager software to 
execute a block diagram similar to FIG. 1. 

FIG. 5 is a diagram of the layout and inter- 
connection of a computer and programmable test 
instrumentation system for stimulating a device un- 
der test and d tecting and analyzing th response 
in accordance with the invention. 



FIGS. 6-11 illustrate the steps of assembling 
a block diagram and associated diagram configura- 
tion data base in the computer of FIG. 5 for stimu- 
lating and detecting a response from the device 
e under test 

FIG. 12 illustrates th further steps of adding 
blocks to the block diagram of FIG. 11 for analyz- 
ing and displaying signal data returned by the 
digitizer from the device under test 
w FIGS. 13 and 14 show the screen of FIG. 12 

during operation of the system to set parameters 
for a selected generator block in the block diagram. 

F1C. 15 shows the step of setting initial or 
default parameters for the digitizer. 
is FIG. 16 shows selection on the pop-up menu 

of the "execute diagram" command to commence 
execution. 

FIG. 16a shows the screen after partial ex- 
ecution of the block diagram, with a graphical dis- 
20 play of a waveform output from the digitizer under 
the initial settings of FIG. 15. 

FIG. 17 shows how the user can modify 
operation of the digitizer by user-interactive, signal- 
viewing control of the signal acquisition window. 
25 FIG. 17a shows the screen after partial reex- 

ecution of the block diagram using the digitizer 
settings modified in FIG. 17. 

FIG. 18 shows the step of modifying the 
digitizer default settings to conform to those set in 
30 FIG. 17. 

FIG. 19 shows the screen after complete 
execution of the block diagram, including graphs of 
the digitizer output waveform and the output of the 
polar block. 

35 FIGS. 20 - 23 illustrate the procedure for 

consolidating a portion of the block diagram of FIG. 
12 into a macro block. 

FIG. 24 illustrates the step of adding the 
macro block to the resource list 

40 FIGS. 25 - 30 illustrate a capability provided 

in the invention for the user to enter a block, such 
as the device under test to view further layers of a 
detail of the structure represented by the block. 
FIG. 31 is a top level state diagram for the 

45 block diagram editing software utilized in the inven- 
tion. 

FIG. 32 is a state diagram of the "editor 
pane red button activity" state in FIG. 31. 

FIGS. 32a, 32b and 32c are state diagrams 
so for the "draw connection," "move block" and 
"move connection" states in FIG. 32. 

FIG. 33 is a state diagram of the "editor 
pane yellow button activity" state in FIG. 31. 

FIC. 34 is a state diagram of the "block 
55 mnu activity" state in FIG. 31. 
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FIG. 34a shows the Block Input state dia- 
grams for the "add an input to block, n remove an 
Input from block" and "label an input" stat s in 
FIG. 34. 

FIG.34b shows the Block Output state dia- 
grams for the "add an output to block," "remove 
an output from block" and "label an output" states 
in F1G.34. 

FIG.35 is a state diagram of the "macro 
menu activity" state in FIG.33. 

FIG.36 is a state diagram of the "macro 
block editor menu activity" state in FIG.33. 

FIG.37 is a state diagram of the "block editor 
menu activity" state in FIG.33. 

FiG.37a is a state diagram of the "create 
macro block" state in FIGS.36 and 37, 

FIG.37b is a state diagram of the "label 
block" state in FIG.36 and 37. 

FIG.37c is a state diagram of the "add new 
block" state in FIGS.36 and 37. 

FIG.38 is a state diagram of the "execute the 
diagram" state in F1G.37. 

FIG.39 is a state diagram of the "blue button 
activity" state in FIG.31. 

HG.40 is a state diagram of the "resource 
list pane yellow button activity" state in FIG.31. 

FIG.41 is a state diagram of the "resource 
list pane red button activity" state in FIG.31. 

RG.42 ic a functional block diagram of sig- 
nal viewing control of a digitizer during block dia- 
gram execution. 

FIG.43 is a top level state diagram of the 
procedure for signal viewing control. 

FIG.44 is a state diagram of the "acquire 
data" state in RG.43. 

FlGS.45a and 46a are state diagrams of the 
"vertical settings" and "horizontal settings" states, 
respectively, in FIG 44. 

FIGS.45b and 46b are diagrams graphically 
illustrating operation of the procedures of FIGS.45a 
and 46a, respectively. 

FIG.47 shows how the user controls opera- 
tion of a power supply via signal viewing control. 

FIG. 48 Is a top level state diagram of the 
procedure for signal viewing control of a power 
supply. 

FIG. 49 shows how the user controls opera- 
tion of a function generator via signal viewing con- 
trol. 

TABLES 1, 2 and 3 summarize examples of 
block functions used in the block diagram editor 
system for signal analysis and test instrument con- 
trol. TABLE 4 shows an alternate form of the Block 
Editor menu, together with a brief summary of the 
functions listed in the menu. 



APPENDIX A is a program listing in C pro- 
gramming language of a block function routine for 
" controlling an example of a stimulus-type test in- 
strument, a function generator, in accordance with 
s the invention. 

APPENDIX B is a C-language program list- 
ing of a block function routine for controlling an 
example of a response-detecting instrument a 
digitizer, in accordance with the invention. 
w APPENDIX C is a description and example 

of a C-language block function routine used in the 
present invention for performing signal analysis, 
polar conversion, on signal data. 

APPENDIX D is a format and example for 
75 the block diagram of FIG. 16 of the netlist created 
by execution of the block diagram. 

APPENDIX E is a C-language listing of the 
definition of SAMPLE in the Experiment Manager. 
APPENDIX F is a C-language listing, with 
20 comments, of a generalized block function. 

APPENDIX G defines the variables em- 
ployed in program for signal viewing control of a 
digitizer. 

APPENDICES H and I are Smailtalk-80 pro- 
as gram listings, with comments, for the methods of 
determining vertical and horizontal digitizer settings 
under signal viewing control. 

APPENDIX J is a Smalltalk-80 program list- 
ing, with comments, for the key methods for con- 
30 trolling a power supply via signal viewing. 



DETAILED DESCRIPTION 

as This description begins with a general descrip- 
tion of the overall hardware and software structure 
as used, first, for signal analysis and, second, for 
managing an experiment involving an electrical cir- 
cuit (device under test). Then, operation of the 

40 system is described from the user's viewpoint 
Finally, the block diagram editor software structure 
and operation are described in detail. 

45 1.0 GENERAL HARDWARE AND SOFTWARE 
STRUCTURE 



so 1.1 Computer System 

Referring to FIG. 5, a computer system 50, 
arranged and programmed in accordance with the 
invention, is connected to an instrumentation sys- 
$s tern 52 to provid an Experiment Manager system. 
Computer system 50 comprises a general purpose 
digital computer 54, conventionally including a cen- 
tral processor and random access and hard disk 
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memory (not shown). A user interacts with the 
computer through a graphic display means 56 and 
user input means including a keyboard 58 and a 
three-button mouse 60. (With some rearrangement 
of the software, a one-or two-button mouse could 
be used.) A suitable form of computer is provided 
by a Tektronix 4404 artificial intelligence worksta- 
tion, which is commercially available with a Tek- 
tronix 4404 integrated CRT display serving as the 
graphic display means and with the aforementioned 
keyboard and three-button mouse. 



1.2 Instrumentation System 

As used in an experiment manager system, the 
computer system 50 is connected to the instru- 
mentation system 52 by data communications 
means including a bi-directional RS-232 data bus 
62, a protocol converter 64 and an IEEE 488 
(GPIB) bi-directional data bus 66. The protocol 
converter is suitably an lOtech Model MAC488 bus 
controller. The test instrumentation system can be 
composed of any of a wide variety of program- 
mable electronic test instruments, compatible with 
the IEEE 488 protocol. Workstations other than the 
Tektronix 4404 can be used, which have a built-in 
GPIB interface, such as the IBM/PC-AT. 

In the illustrated example of test instrumenta- 
tion system 52, three signal generating instruments 
68, 70, 72 and a signal detecting instrument 74 are 
shown connected to bus 66. Each of the signal 
generating instruments is connected via suitable 
conductors 69. 71, 73 to a device under test 76 
comprising an electrical circuit. Conductors 69, 71, 

73 are connected via suitable probes to locations in 
the device under test to stimulate the circuit as 
determined by the user. The response-detecting 
device 74 is similarly connected via a conductor 75 
and suitable probe to a test point of interest on the 
circuit of device 76. 

For purposes of example to illustrate applica- 
tion of the invention to management of an experi- 
ment, the device under test 76 is an amplitude 
modulator. The stimulating test instruments 68 and 
70 are each a Tektronix FG5010 Progammable 
Function Generator and instrument 72 is a Tek- 
tronix Model PS5010 programmable power supply. 
An alternative example of test instruments 68, 70 
can be the Analogic Corp. Model DATA 2020 
polyonomial waveform synthesizer, which is also 
programmable and controllable by IEEE 488 pro- 
tocol. The response-detecting instrument 74 is 
preferably a Tektronix Model 7D20 digitizer. An 
alternate example of response-detecting instrument 

74 is a programmable spectrum analyzer. 



1.3 General Software Structure 

For purposes of the example described herein, 
computer 54 is assumed to be a Tektronix 4404 

s workstation programmed to run programs written in 
SmalItalk-80 and C programming languages under 
Uniflex or another UNIX-like operating system. The 
computer is further programmed, In accordance 
with the invention, with block diagram editor and 

w execution manager software structured as shown in 
RG. 3. The block editor software is preferably 
implemented in Smalitalk-80 or other object-ori- 
ented programming language. Such languages are 
known and described in the art, for example, in A. 

75 Goldberg, "Smalltalk-80, the Interactive Program- 
ming Environment" published by Addison-Wesley 
(1984); "4404 Artificial Intelligence System: Intro- 
duction to the Smafltalk-80 System" published by 
Tektronix (1984); and BYTE Vol. 6, No. 8 (August 

20 1981) and Vol. 1 1, No. 8 (August 1986). Portions of 
the execution manager software are based on a 
modification of BLOSIM, referred to herein as 
IBLOSIM (for Interactive BLOck SIMulator), as 
shown in FIG 3c and described in Section 4.0. 

25 These portions have been implemented in C pro- 
gramming language, which is well-known in the art, 
and the remainder is programmed in Smalltalk-80. 

30 1.3.1 Block Editor Software 

This software operates under control of a Block 
Editor Main Control routine, indicated by block 80. 
The software structure includes a Select Block rou- 

35 tine 82, which is first invoked by the Block Editor 
Main Control routine. When actuated by the user 
as described below, this routine takes a selected 
block from a prestored resource list 83. Control is 
then shifted to a Position Block routine 84 which in 

40 turn accesses a Display Block routine 85 which 
causes conventional graphics software to display 
the selected block on the graphical display 56. The 
displayed information is stored in a display in- 
formation memory 86 that continues to be updated 

46 as a block diagram is assembled on the computer 
by the user. 

After positioning two or more blocks on the 
display, the user can then invoke a Connect Blocks 
routine 88. This routine in turn enables a Display 

so Connection routine 89 to display interconnections 
selected by the user. These interconnections are 
also stored in the display information memory 86. 

Once the block diagram has been assembled, 
the user can invoke a Set Parameters routine 90. 

55 Many of the functional blocks, such as those repre- 
senting instruments 68, 70, 72 and 74, requir that 
initial or default settings of parameters for operation 
of th instruments be input to the system. Invoking 
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routine 90 for such a block causes a Display Pa- 
rameters routine 91 to display a table of param- 
eters for the instrument associated with the block. 
The user then fills in the desired parameters. As 
this is done for each block, the display parameters 
are added to the display memory. 

Each of routines 84, 88 and 90 also provides 
block position, interconnection and parameter set- 
ting information to a diagram configuration data 
base 87. This data base is structured to provide 
data used by the execution manager software, de- 
scribed below, to create a netlist in the format of 
APPENDIX D that is used by the execution man- 
ager to control execution of the block diagram. In 
an operative embodiment of the system, this netlist 
is compiled after the block diagram has been fully 
assembled but, alternatively, it can be compiled 
incrementally, as the block diagram is being as- 
sembled, to attain faster execution. 

The block editor's operation is described in 
more detail in Section 2.2 and its software structure 
is described in Section 3.0. 



1.3-2 Execution Manager Software 

After completing a block diagram, the user 
actuates the execution manager software through 
the Block Editor Main Control routine. This action 
invokes an Execute Diagram routine 92, which cre- 
ates from the block diagram data stored in data 
base 87 a netlist such as that of APPENDIX D, to 
control execution of the diagram. Routine 92 also 
accesses a prestored Function Execution Library 
93, containing block function application subrou- 
tines that correspond to and implement each of the 
functions in resource list 83. The netlist dictates to 
the Execute Diagram routine which functional sub- 
routines to use and how to Bnk these subroutines 
for execution in the sequence embodied in the 
diagram. 

As each function of the diagram is being ex- 
ecuted, interim and output data are stored in an 
execution data storage 94. Then, as execution of 
each function is completed, the stored data is 
either output to the next function routine as deter- 
mined by the netlist interconnections, or returned 
to the function subroutine to generate control set- 
ting commands for transmission via the commu- 
nications channel to the appropriate test instrument 
of instrumentation system 52. 

During execution of each block, the Execute 
Diagram routine provides a command to the Main 
Control routine to cause the block being executed 
to be highlighted on th display. In this stage of 
operation, the user can intervene in execution of 
the diagram to alter the parameters of a selected 
block and its associated function and re-execute 



the diagram. This capability is particularly useful to 
enable the user interactively to control the opera- 
tion of the test instruments. It Is further enhanced, 
for control of test instrumentation, by addition of a 

5 signal viewing capability that enables th user to 
display and manipulate features of operation of the 
test instruments in two dimensions. This capability 
is described below in Section 5.0. 

Section 2.1 below outlines operation of the 

70 execution manager to execute the block diagram of 
RGS. 1 and 2. Section 4.0 is a more detailed 
description of the software structure of the execu- 
tion manager. 

76 

2.0 SYSTEM OPERATION 



20 2.1 Signal Processing 

RGS. 1 and 2 illustrate a simple application of 
the block diagram editor system of the invention to 
a signal processing problem. In this example, the 

2s user has constructed a block diagram, shown in 
RG. 1, to generate and process a signal. Upon 
execution of the block diagram and underlying soft- 
ware assembled as described above, the originally- 
generated signal and signals output from the sub- 

30 sequent processing steps are graphed, as shown in 
FIG. 2. 

Upon execution, the current block diagram is 
first checked for validity, I.e., to make sure all 
connections are proper. Next, in operation of the 
35 execution manager software, the Smalltalk process 
96, shown on the left side of RG. 4, is "forked" 
into a C process 97, shown on the right side of 
RG. 4. The C process runs as a child process of 
the Smalltalk process, using pipelines 98, 99 for 
40 transfer of information between the two processes. 

The Smalltalk process 96 converts the block 
diagram that the user has constructed into a netlist 
formatted like that in APPENDIX D. This is done by 
scanning the underlying data structures corre- 
45 sponding to the current block diagram, as stored in 
diagram configuration data base 87 (RG. 3), and 
creating a list of all the blocks, their parameters 
and their connections. Then, the netlist is shipped 
to the C process, which includes a netlist inter- 
so prefer and the Function Execution Library 93. The 
netlist interpreter handles the setup, scheduling 
and execution of the block functions Under this 
routine, the netlist is interpreted, the parameters 
are set for the various block function routines 
55 called by the netlist, and th routines are sched- 
uled and then executed. Th routines are sched- 
uled to be executed in an order determined by the 
direction of data flow indicated by the interconnec- 
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tions shown in the diagram. 

Before the function corresponding to each 
block commences execution, a block inversion re- 
quest is transmitted by the C process 97 to the 
Smalltalk process 96 via pipe 99. In response to 
this request, the Smalltalk process causes the 
graphics software to reverse video or highlight the 
block to be executed to provide feedback to the 
user. In the case of signal view control, e.g., of the 
digitizer, this gives the user an opportunity to modi- 
fy the parameters of the block about to be ex- 
ecuted, as discussed further below. 

Error messages and waveform data are trans- 
ferred back to the Smalltalk process during execu- 
tion of the block diagram. Such transfers cause 
graphical display objects to appear, if they do not 
already exist These display objects then read and 
display the error messages or waveform data. The 
names of the blocks from the original block dia- 
gram are installed as the titles of the graphical 
display objects. When the entire diagram has fin- 
ished executing, the C process dies and control 
returns to the user via the BIockEditor user inter- 
face. 

In regard to the example of FIGS 1 and 2, the 
sequence of execution commences with the rou- 
tines corresponding to generator blocks, which 
generate signal data at their outputs. The example 
illustrated in FIGS. 1 and 2 shows generation of a 
sine function, sin(x). Execution then proceeds to 
the routines corresponding to transforming blocks, 
which accept and transform the signal data and 
provide modified signal data at their outputs. The 
example shows successive transformations, first, of 
the sine function signal by a fast Fourier transform 
(Rfft) and, second, by a polar conversion function 
(Polar), a listing for which is contained in APPEN- 
DIX C. 

Finally, the output signal data are input to ap- 
propriate routines for the terminal blocks shown in 
the block diagram. The example of FIGS. 1 and 2 
shows two such blocks (Graph), each of which has 
the function of graphing the signal data output from 
the block to which it is connected. An alternative 
form of block (e.g., "sink" in FIG. 4) can be used to 
dead end any signal data that is not of Interest. 
The output of each Graph block is then transmitted 
back to the Smalltalk process, via pipe 99, for 
graphical display as shown in FIG. 2. 

This simple example shows how the system of 
the invention can be used for simulation purposes. 
As will be seen from the ensuing description, a live 
signal could alternatively be input to computer sys- 
tem 50 via an appropriate communications inter- 
face for analysis similar to that illustrated in FIGS. 
1 and 2. Similarly, signals can be generated in the 



manner illustrated by FIGS. 1 and 2 and output, 
through an appropriat interface, either directly to a 
communications system or in the form of control 
setting commands to other test instruments. 

5 

2.2 Experiment Manager 

This section describes how a user interacts 
10 wfth a computer system 50 and the software of the 
invention to build, modify and execute block dia- 
grams for purposes of managing an electrical cir- 
cuit experiment. It is equally applicable to any of 
the foregoing applications. In this description, op- 
15 eration of the three-button mouse is couched in 
terms of button color, as used in the Coldberg text, 
i.e., the left or "select" button is red; the middle or 
"menu" button is yellow; and the right or "window" 
button is blue. 

20 

2.2.1 Editing and Resource Panes 

Referring to FIG. 6, upon start-up, the user will 

25 > see a view on 100 on screen 56 with "BIockEditor" 
in title tab 102. If there is no BIockEditor view on 
the screen, the user enters the following text in the 
work space: "BIockEditor openOn: Universe new" 
and then selects this line of text and executes it 

30 The user then designates a location for the BIoc- 
kEditor view in response to a prompt 

The BIockEditor view comprises two panes, an 
editor pane 104 on the left and a resource list pane 
106 on the right The resource list can be a multi- 

35 pane list The BIockEditor view 100 may contain an 
entire block diagram, in which case the title tab will 
read "BIockEditor," or it may contain a "macro 
expansion," in which case the title tab 102 will 
contain the name of the macro, e.g., 

40 "amModulation Experiment", as shown in FIG. 6. 
The term "macro" refers to a collection of blocks 
and connections that have been grouped into a 
higher level module and the term "macro expan- 
sion" is the expanded display of that macro. The 

45 term "macro expansion BIockEditor" will refer to a 
BIockEditor view in which a macro expansion is 
being edited. 

The editor pane can contain (1) blocks-labeled 
rectangles with white interior; (2) macros-labeled 

so rectangles with patterned interior; and (3) 
connections-lines connecting block or macro out- 
put terminals (black dots, by convention to right of 
the block) to block or macro input terminals (small 
circles, by convention to the left of the block), as 

55 sh wn in FIG. 9. 

The resource pane has a vertical scroll bar 
107, which appears when th cursor is in the 
resource pane, as shown in FIG. 6. It disappears 
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when the cursor is moved into the editor pan , as 
shown in FIG. 7. The editor pane has X-Y scroll 
bars 108, 110, also as shown in FIG. 7. Individually, 
the scroll bars work just like a conventional Small- 
talk vertical scroll bar. Simultaneous X-Y scrolling 5 
can be actuated by depressing the left shift key on 
keyboard 58 and pressing the red button on mouse 
60. The left shift key can then be released. As long 
as the red button is held down, the screen will 
scroll in two dimensions. 70 



2.22 Pop-up Menus 

The editor pane has three pop-up menus, each 15 
of which contain a collection of editing commands. 
All three pop-up menus are invoked by pressing 
the yellow mouse button. The first menu is the 
BlockEditor menu 112, shown in FIG. 9. This menu 
is brought up by pressing the yellow mouse button 20 
while the cursor 114 (FIG. 8) is not inside a block 
or a macro. When the BlockEditor menu is brought 
up in a macro expansion view, two additional 
commands-"accept tt and "cancer-are included 
and the "execute diagram" command is omitted. 25 
Other combinations of functions can be included in 
the BlockEditor menu, for example, as shown in 
TABLE 4. 

The second form of menu is a block menu 116, 
as shown in FIG. 13. The block menu is brought up 30 
by pressing the yellow mouse button with cursor 
1 14 (FIG. 8) inside a block. 

The third form of menu is a macro menu, 
which is brought up by pressing the yellow mouse 
button with cursor 114 inside a macro block, It has 35 
one menu item: 
enter macro. 

The resource list pane 106 contains a list of 
available functions, which is stored in resource list 
memory 83 (FIG. 3). A function is selected from 40 
this list by placing the cursor on the function name 
and pressing the red mouse button. The resource 
list pane has one yellow button menu with one 
menu Mem: remove entry. The "remove entry" 
operation deletes the selected function from the 45 
resource list pane and deletes the software asso- 
ciated with that function from the system. 



2.2.3 Constructing Block Diagrams 50 

A block or macro is added to a block diagram 
in editor pane 104 by selecting its name from the 
resource list in pane 106. In FIG. 6, the 
"amModulator" function 116 has been selected. 55 
After selecting, the user moves the cursor into the 
editor pane and the cursor will change to represent 
the selected function as a block 118, as shown In 



FIG. 7. To place the block, the user moves it to a 
desired location by moving the mouse and posi- 
tions th block by pressing the red mouse button. 
As shown in FIG. 8, the cursor will change back to 
the normal cursor, in the form of an arrow 114, and 
the block will be fixed in position on the editor 
pane. Small circles 120 on the left side of block 
118 indicate input terminals and a small circular 
spot 122 on the right side of the block indicates an 
output terminal. 

A block label 124 appears in the block 118. 
Initially, the block label is identical to the function 
name for the function selected from resource pane 
106. Block rabels must be unique so the block 
diagram editor software will attach an asterisk to 
the block label of a selected function if another 
block bearing the same label has already been 
positioned in editor pane 104. The user can, how- 
ever, change the label of a block. 

Referring to FIG. 9, the user can continue to 
build up a block diagram by selecting functions 
from resource pane 106 and positioning each se- 
lected function as a block in editor pane 104. In the 
same manner that the user selected and positioned 
block 118, the user can select and position blocks 
representing two function generators 126, 128, a 
power supply 130 and a data acquisition device 
132. Comparing FIG. 9 and FIG. 5, it can be seen 
that the block diagram contains functional blocks 
corresponding to the test instruments 68, 70, 72 
and 74 connected to the device under test 76 in 
instrumentation system 52. 

To make the block diagram descriptive of the 
function that it is performing, the user can modify 
the names of the blocks. To do so, the user in- 
vokes the BlockEditor menu 112 and selects the 
item "label block" shown in the menu. Referring to 
FIG. 10, the display provides a cursor 134 to the 
user Label which block? The user positions the 
cursor on the block that is desired to be renamed 
and presses the yellow mouse button. 

Referring to FIG. 11, block 130 has been se- 
lected. This action causes a prompt to appear over 
the selected block, requesting the user to type in a 
new block label. As it is typed in, the new label 138 
appears in prompt 136. When the user presses the 
yellow mouse button, the new label is inserted in 
the selected block. FIG. 12 shows blocks 126, 128, 
130 all relabeled using this procedure. The same 
name must not be duplicated in any other blocks in 
a block diagram because these names are later 
used in the netlist that is used to execute the 
diagram (see APPENDIX D). 

Returning to FIG. 9, before a diagram can be 
executed, all of the inputs and outputs must be 
connected. To connect an output to an input, th 
user moves the cursor to an output of a block, for 
example, output 122 of block 118, and presses the 
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red mouse button. The user then moves the cursor 
away from th output and the BIockEditor software 
displays a line ext nding from the output to th 
current cursor position. To complete a connection, 
the user points the cursor to an input, such as input 
140 of block 132, and depresses the red mouse 
button. A connection 142 is then drawn between 
output terminal 122 and input 140. Connections are 
drawn in like manner between the output terminals 
146 of blocks 126, 128, 130 and the input terminals 
120 of block 118. To facilitate routing of connectors 
144, the user can choose to put points 148 in the 
interconnection lines to produce an interconnection 
routing with only horizontal and vertical lines and to 
avoid other blocks. This is done by pressing the 
red mouse button at each location where direction 
of the interconnection line is to change. 

The user can also modify connections that 
have been made. To select a connection, the user 
moves the cursor to one of the connection points, 
either an end point or one of points where direc- 
tions changes, and press the red mouse button. To 
select an end point, the user places the cursor in 
the center of the input or output terminal. The 
connection will highlight indicating successful se- 
lection. To move a connection point the user 
moves the cursor to that point and presses the red 
button. The line or lines connecting to that point 
will "rubber band" and the user moves the point to 
its new location and releases the red button. End 
points of interconnection lines can be moved to 
any unused input or output To delete a connec- 
tion, the user moves any of the connection points 
outside of the BIockEditor pane 104. To reroute a 
connection, the user deletes the connection and 
redraws it A selected connection may be deselec- 
ted either clicking the red mouse button on it again 
or by selecting something else in the diagram. 

The user can also select and either move or 
delete a block that is already on the diagram. The 
user does this by positioning the cursor within the 
block and pressing the red mouse button. The 
block will highlight, indicating selection. To move a 
selected block, the user moves the cursor to that 
block, presses the red mouse button, drags the 
block to a new location, and releases the red 
button. To delete a block, the user selects it and 
drags it outside of the editing pane and releases 
the red button. To add a block to the resource list 
the user drags the block into the resource list pane 
106 and releases the red button. If the block's 
name Is not already there, it will be added to the 
resource list. 

Referring to FIG. 12, additional blocks can be 
added to the block diagram as needed for a par- 
ticular exp riment For exampl , signal analysis 
blocks 150, 152 are conn cted in series to an 
output terminal 154 of signal acquisition block 132. 



Connected to one output terminal 156 of block 152 
is a "graph" block 164. Connected to the other 
output t rminal 160 f block 152 is a "sink" block 
162. Blocks 150, 152 perform signal analyses on 

5 the signal output from block 132 at terminal 154. 
The names of these blocks are stored in the re- 
source list pane 106 and. the BIockEditor software 
includes subroutines, selectable by selecting the 
associated function name and block, for performing 

to the function Indicated by the function name. Block 
164, also selected from the list in pane 106, in- 
vokes a graphing function for graphically displaying 
the signal that is output on terminal 156 from block 
152. Block 162, "sink," is also listed in pane 106 

75 and enables the user to disregard data from output 
terminal 160 of block 152. 



2.2.4 Setting Initial Block Parameters 

20 

Referring to FIG. 13, some blocks have initial 
or default parameters for the user to set The user 
does this by moving the cursor into a block whose 
parameters are to be set invokes the block menu 

25 116. and selects "set parameters" from the menu. 
If the block has no parameters, the cursor will 
remain a normal, arrow cursor. If the block has 
parameters, the cursor will change to a "wait" 
cursor, followed shortly by a prompt to locate a 

30 parameter view. In FIG. 13, the user has selected 
block 128, which represents and controls the func- 
tion generator 70 in FIG. 5. A parameter view or 
menu 168 for the selected block then appears, as 
shown in FIG. 14. 

35 The parameter view is divided into left and 
right sides. The panes on the left side define the 
parameters of the particular block. The panes on 
the right side of the view are used to specify the 
settings of the parameters for the function asso- 

40 dated with the selected block. In some cases, the 
parameter can be expressed as a series of buttons, 
as in the case of the "waveform" parameter in 
menu 168. The user can select one of the choices, 
e.g., "sine", by placing the cursor over it and 

45 depressing the red mouse button. If the parameter 
is not specified by buttons, the user moves the 
cursor into the right side pane and types in a 
number to specify the requested parameter. Once 
the parameters have been input the user accepts 

so the parameters by selecting "accept* 169 from the 
BIockEditor menu invoked by pressing the yellow 
(middle) mouse button while the cursor is still in 
the parameter view. 

FIG. 15 shows the foregoing parameter-setting 

55 procedure as applied to digrtiz r 74, repres nt d in 
the diagram as block 132. The operation of digitizer 
74 is initially controlled by default parameters pro- 
grammed into the associated block 132 when ini- 
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tially constructed. These parameters can be reset 
in the same manner as for generator blocks 126, 
128, 130. Referring to FIG. 15, selecting th "set 
parameters" item brings up the parameters pane 
170 for block 132. Th format of this pane is s 
similar to parameter pane 168 (FIG. 14), previously 
described. The user can select the various buttons 
shown on the pane and Input the numerical param- 
eters desired to specify initial or default operation 
of digitizer 76. The values shown are exemplary w 
default or initial settings that can subsequently be 
modified interactively by the user during execution 
of the diagram. To interactively modify these de- 
fault parameters, the user selects "no" after the 
query "Use acquisition window." is 



2.2.5 Executing a Block Diagram 

Once assembled, the block diagram can be 20 
executed. To execute a block diagram, the use 
selects "execute diagram" from the BlockEditor 
menu 112, as shown in FIG. 16. If all of the inputs 
and outputs are connected, the diagram will ex- 
ecute; otherwise, an error notification will appear. If 25 
that happens, the- user can press the red mouse 
button to proceed with connecting any unconnec- 
ted outputs. 

There will be a short pause after selecting 
"execute diagram" and then each block will 30 
"reverse video" as the processor executes the 
associated functions in the software. Some blocks 
prompt the user to specify a location to display an 
output set of signal data. After a location is speci- 
fied, execution of the block diagram continues. If 35 
the diagram is reexecuted, and the data display 
windows are still present the new data will be 
automatically routed to those windows. 

FIG. 16a shows an example of the windows 
appearing on display 56 after partial execution of 40 
the block diagram of FIG. 16. Window 172 displays 
a waveform output from digitizer 74 to computer 
system 50. The signal viewing menu 174 can be 
invoked at this point in the operation to enable the 
user to modify the signal acquisition window of the 45 
digitizer. 



2.2.6 Modifying Block Parameters 

50 

During execution of the diagram, however, the 
user can modify operation of the digitizer inter- 
actively by changing the signal acquisition window 
thereof on th graphic display 56. FIGS. 16a, 17, 
17a, 18 and 19 illustrate this procedure from the 55 
us fs viewpoint Section 5.0 describes the internal 
structure and operation of this capability. 

The user selects the desired form of signal 



viewing control on menu 173 in FIG. 16a. For this 
example, the user has selected "zoom in." This 
command invokes a standard Smalltalk-80 routine 
that prompts the user to d signate a rectangle 174 
which encompasses a portion of the signal that is 
of interest to the user. This rectangle can be either 
smaller or larger than the displayed signal, al- 
though its effectiveness is constrained by the capa- 
bilities of the instrument being controlled, as dis- 
cussed in Section 5.0. 

To define this rectangle, as shown in FIG. 17, 
the system displays an upper left comer symbol 
(not shown), vhich the user positions by depressing 
and holding down the mouse pointer button. Then 
the user moves the mouse pointer to position the 
lower right comer of rectangle 174, and then re- 
leases the button. The designated area is stored, 
as a variable screen Rect which is then processed, 
as described in Section 5.0, to establish a new 
signal acquisition window corresponding to rectan- 
gle 174. 

FIG. 17a shows the windows after partial re- 
execution of the block diagram using the new sig- 
nal acquisition window specified by rectangle 174. 
A new waveform is displayed in window 172. It 
corresponds to the waveform shown in FIG. 16a 
but is based on newly acquired data, not merely an 
expansion of reformated, stored data from the prior 
execution. 

The user decides whether the waveform shows 
what is desired. If not the user can again modify 
the signal acquisition window. Once satisfied, the 
user can again invoke the parameter view 170 from 
window 104, as shown in FIG. 18. The values 
displayed are those derived from the desired ac- 
quisition rectangle 174. This time the user selects 
these values for complete execution of the block 
diagram by answering "Yes" to the query "Use 
acquisition window." Alternatively,^ the user can 
again invoke menu 173 (FIG, 16a) and select "Use 
acq window," to perform the same function. 

The diagram is then executed completely, with 
the results being shown in FIG. 19. Window 172 
again displays the digitizer output waveform for the 
desired acquisition rectangle 174. Window 178 dis- 
plays a graph of the amplitude output of polar 
analysis block 152, as specified by the connection 
to graph block 164. 



2.2.7 Creating Macros 

At times it may be desirable to group several 
blocks together and treat them as if they were one 
functional block. This is accomplished by using the 
"build macro" menu function, as shown in FIG. 20. 
All the functions that are intended to be included in 
the macro must appear in the editor pane 104 and 
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must be appropriately connected. The user posi- 
tions th cursor in th editor pane and selects 
"build macro" from the BlockEditor menu 112. The 
cursor changes from an arrow t a swirl 114a, as 
shown in FIG. 21 . The user then locates the cursor 
on each block and presses the red button once to 
include that block in the macro. The blocks will 
highlight as they are selected. 

Once all blocks to be included in the macro 
have been selected, the user moves the cursor to 
an open area of the editor pane and presses the 
red button twice. The highlighted blocks and asso- 
ciated connections are then erased from the dis- 
play screen, as shown in FIG. 22, and the user is 
prompted to type a name into box 176. A unique 
name must be applied to the macro to distinguish 
from the names of other blocks already in use. 
Once a name is provided, the cursor will then 
change to represent a macro block which can be 
positioned In the diagram, as shown in FIG. 23. 
The connections from blocks inside the macro to 
blocks outside the macro will then be redrawn. 

In FIG. 21, the user has selected blocks 150, 
152, 162, 164 for inclusion in a macro. In FIG. 23, 
after assignment of a name, the functions of all of 
these blocks are included in a single block 180, 
named "magSpectrum." This is the "bottom up" 
way to create a macro. 

Once created, a macro behaves just like any 
other block, and can be added to the resource list 
in pane 106. Referring to FIG. 24, to add a block to 
the resource list, the user drags it, using the mouse 
with the red mouse button depressed, into the 
resource list pane and releases the red mouse 
button. Since the macro is a newly created block, 
its name is added as label 182 to the resource list 
Block 180 will continue to be displayed at its last 
location. 

There are also two "top down" ways to create 
a macro. First a non-defined function named, for 
example, "empty macro" can be included in the 
resource list pane 106 for the user to select and 
position in the editor pane 104. Once it is posi- 
tioned it should be relabeled to reflect its intended 
function. Second, if there is no "empty macro" 
function in pane 106, the user can move the cursor 
into the editor pane to 104 and select "add block" 
from the BlockEditor menu 112. The cursor will 
change to represent an empty block which the user 
can move to a desired location and position by 
clicking the red mouse button. The block is then 
labeled to reflect its intended function. The user 
will be prompted for the block parameters but none 
are required for macros. The user can position the 
curs r in the parameter work space, delete every- 



thing between parentheses, and select "accept" 
from the BlockEditor menu. Next th user selects 
"become macro" from the block menu 116. The 
block will then become an empty macro. 

5 

2.2.8 Editing Macros 

To edit a macro, the user moves the cursor 

10 inside the macro and selects "enter macro" from 
the macro menu. The user is then prompted for a 
screen location for a new macro expansion Bloc- 
kEditor view. This view will have the macro's label 
as its title tab, indicating that a macro is being 

75 edited. If the macro is empty, the editor pane will 
be empty; otherwise, the blocks that constitute the 
macro will be displayed. The diagram can be ed- 
ited like a top-level block diagram, with one excep- 
tion. When the editing session is done, the user 

20 selects either "accept" to save the edited macro or 
"cancel" to delete all changes since the last 
"accept" The macro expansion BlockEditor view 
may then be closed. 

The user then moves the cursor to the next- 

25 higher BlockEditor view (if there are macros within 
macros, one can be a few levels down), and select 
"repaint" from the BlockEditor menu 112. Any ex- 
ternal changes to the macro, e.g.. number of inputs 
and outputs, will be displayed. Connections will be 

so broken if blocks in the macro to which they were 
originally connected have been connected to an- 
other block or removed. The result of editing a 
diagram before "repaint" is undefined. 

To parameterize blocks in a macro, the user 

35 selects "enter macro" in the macro menu. Then, 
the user parameterizes each of the blocks in the 
macro independently as previously described, en- 
tering "accept" for each set of parameters in turn, 
and then entering "accept" for the macro as a 

40 whole. The macro expansion BlockEditor may then 
be closed. 



2.2.9 viewing Block Information 

45 

Just as a macro includes internal blocks, a 
block may have some information, such as a tex- 
tual document or a schematic associated with it To 
view this information, the user selects "enter block" 

so from the block menu. If the block has no informa- 
tion, nothing will happen. If the block has any 
information, the user is prompted to designate a 
display location. 

Referring to FIG. 25, the user has selected 

55 block 118, the d vice under test, for viewing 
prestored background information. At the first level 
below that of block 118, a prepared schematic of 
the device under test is displayed in FIG. 25a. 
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Referring to FIG. 26, the user has selected an 
integrated circuit at the center of the schematic. 
The selection provides two options: "open sub- 
level* and "information. " The "information 0 option 
enables the user to examine or add notes about s 
the device, as shown in FIG. 27. The "open sub- 
lever brings up a block diagram for the selected 
circuit device, as shown in FIG. 28. This informa- 
tion would ordinarily come from the data book 
about the circuit device, which can be input by the io 
user or obtained online or in machine readable 
form from the vendor. By selecting the block dia- 
gram, the user can descend to another level of 
detail, again using the two options "open sublevel" 
and "information." FIG. 29 shows textual informa- is 
tion regarding the block diagram of FIG. 28. RG. 
30 shows a schematic for one of the blocks in the 
block diagram of RG. 2a 



2^.10 Other Block Editing Functions 

A number of functions, not shown in the draw- 
ings, are included in the block diagram editor pro- 
gram. These functions do, however, appear on the 2S 
menus. Their operation is described as follows: 

To erase an entire diagram, the user selects 
"clear" in the BlockEditor menu. A confirmation 
prompt asks the user if he really wants to clear the 
diagram. A "yes" selection will completely erase oo 
the diagram. A "no" selection will return control to 
the BlockEditor, leaving the diagram unchanged. 

The software also permits the user to display 
the labels associated with input and output termi- 
nals of blocks. When the user selects "show la- 35 
bels" from the BlockEditor menu, labels will appear 
for all of the inputs and outputs on the currently- 
displayed blocks: To restore the diagram without 
labels, the user selects "repaint" from the Bloc- 
kEditor menu. To change the input or output labels, 40 
the user selects either "label input" or "label out- 
put" from the block menu. The cursor will change 
to either the label input or the label output cursor. 
The user positions the cursor on top of the input or 
output to be relabeled and clicks the red mouse 45 
button. A prompt appears requesting the user to 
type in the new name. When completed, to exit this 
mode, the user selects "clear mode" from the 
BlockEditor menu. To view the new labels, the user 
selects "show labels" from the BlockEditor menu so 
as described above. 

The system also provides error messages to 
the user. Some of the actions that produce an error 
message include: connecting an output to an out- 
put or an input to an input; putting a block too 55 
close to another block; or trying to make more than 
one connection to an Input or output terminal. 
Pressing the red mouse button will eras the error 



message so that the user can continue editing. If 
the user is doing something other than positioning 
a block, he releases the red mouse button to 
continue editing. If positioning a block, the user 
moves the cursor to the desired block location and 
then releases the red button. 



22.11 Adding Blocks to the Resource List 

Blocks can be added to the system resources 
list, as shown in resource pane 108. The procedure 
for adding a block has two major parts: first, add a 
star interface function to the Function Execution 
Library software (FIG, 3) to fcnable the block to be 
executed and, second, add the block to the re- 
source list The first step in the procedure is ex- 
plained below in Section 4.5, which describes the 
block function building procedures in detail. 

After the star function has been created, the 
user adds the function to the BlockEditor resource 
list as follows: The user selects "add block" from 
the BlockEditor menu. The user then places as 
many blocks in the editor pane as are desired to 
be added to the resource list The user then se- 
lects "add input" from the block menu, and adds 
the appropriate number of input circles by clicking 
the red mouse button on the left side of the block 
once for each input to be added. Next, the user 
selects "add output" and adds output dots to the 
right side of the block. If too many inputs or out- 
puts were added, they may be deleted by selecting 
"remove input" or "remove output" from the block 
menu. The user places the cursor over the input or 
the output to be removed and clicks the red mouse 
button. The user then selects "clear mode" once 
the correct number of inputs and outputs have 
been applied to the blocks in the editor pane. 

Next the user selects "label block" from the 
BlockEditor menu and selects a block to be label- 
ed. The block must be labeled with the name of 
the execution manager star routine. The initial 
block label designates the block function and is 
always remembered even when the block is re- 
labeled. 

The user will then be prompted to build the 
block parameters by editing the following line: 

#Cquestion1' f answer1 r 'question^ 'answer 
'questions' 'answer3' 'question^ 'answert* 
'questions' 'answers' 'questions r answer6*). 

The workspace in which this line appears contains 
a standard Smalltalk editor. The user replaces the 
"qu stionm" with the nam of the parameter 
"answerm" with an appropriate default answer, 
leaving quotes around the questions and answers. 
If the user desires the answer to be a set of 
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buttons, "answerm" (including quotes) is replaced 
with #fbutton1" "button2" n button3"). The labels 
given to the buttons will be the actual text sent to 
the star routine at the time of diagram execution, 
as shown in the example below. The user may add 
more questions/answers pairs as needed and 
should delete unused pairs. If the block does not 
have any parameters, the user selects all of the 
text between parentheses and deletes it. The user 
then selects "accept" from the BlockEditor menu in 
the editor pane once the parameters have been 
specified. 

As an example, the "polar" block parameters 
(APPENDIX C) are specified as follows: 

^units' #CRAD' 'GRAD' 'DEGREE') 'unwrap 1 
#(TRUE 'FALSE*) 'delay' '1.0') 
At this point, the user can give the block input and 
output terminals meaningful names and, if desired, 
can relabel the block. When the block is finished, 
the user selects it and positions it in the resource 
list pane 104, as previously described. 



2.2.12 Simulation Block 

In development of electrical circuits and other 
physical devices, it is conventional practice to de- 
velop a computer simulation of the device prior to 
making it Once the device is built it is tested and 
its operation compared to the results of the simula- 
tion. Conventionally, these steps are performed in 
separate sequential operations and, typically, the 
comparison is made manually. This is time con- 
suming, error-prone and offers little opportunity to 
test alternative operating conditions. 

The present invention enables simultaneous 
generation and comparison of simulation and actual 
test data. This is done by adding the simulation 
program for the device under test as a functional 
block as well as the information provided in Section 
2.2.9. Such a block is added in accordance with 
the procedures described in Section 2.2.11 and the 
Sections referenced therein. 



3.0 INTERNAL STRUCTURE OF BLOCK EDITOR 

This section provides an overview of the 23 
Smalltalk object classes which constitute the Bloc- 
kEditor program, together with their relationships. 
Throughout this section, the Smalltalk naming con- 
ventions are used-class names and global vari- 
ables are capitalized and instances of classes are 
not capitalized. 



3.1 Classes Central to the Block Editor 

The block editor is most simply described as a 
model with two view-controller pairs. The model is 
s class Universe, with the two view-controller pairs 
being BlockEditorView-BlockEditor and 
BlockUstView-BlockListController. FIG. 3a shows 
these relationships, with dotted lines indicating de- 
pendency relationships. 



3.1.1 Universe 

Class Universe maintains all the data about the 
75 block diagram and the system resources in data 
base 87 (FIGS. 3 and 3c). The blocks and connec- 
tions data structures it contains are sent to the 
execution manager for preprocessing by the dia- 
gram scanner 352 preparatory to execution by 
20 IBLOSIM (blocks 354 and 356 in FIG. 3c). The 
instance variables in Universe are: 

blocks: a dictionary of blocks and galaxies, i.e. , 
groups of blocks (stars), which point to correspond- 
ing displayBlocks and displayGalaxies. The blocks 
25 and galaxies correspond to the blocks and macros 
of a block diagram. 

connections: a dictionary of connections which 
point to displayConnections. 

saved Blocks: points to the global variable 
30 CannedBlocksUst, which is a dictionary containing 
the resources available to the block editor. This list 
is displayed in the BIockListView. The format of 
CannedBlocksUst is the same as that of blocks. 
dataDisplays: a dictionary containing the names 
35 of blocks which perform data display functions 
(such as the graph or scalar blocks). Entries point 
to the corresponding object which does the actual 
data display. 

listlndex: the index of the currently selected 
40 resource in the BIockListView. 

onGalaxy: a Boolean which is true if this 
BlockEditor is editing a galaxy (macro), false other- 
wise. 

currentGalaxy: if onGalaxy is true, this points to 
45 the galaxy (macro) being edited. 

modelPtr: if onGalaxy is true, this points back to 
the parent universe or galaxy. 



so 3.1.2 BlockEditor 

The BlockEditor class is the controller for the 
block editor, it receives all the mouse activity 
(keyboard activity is usually requested by the other 
55 classes) and, if necessary, asks th universe to 
modify itself. Some activities, such as 
adding/moving a connection, or building a galaxy, 
require that the controller collect a large amount of 



15 



29 



EP 0 295 760 A2 



30 



data and then send it to the universe. The Bloc- 
kEditor also contains the method which initiates the 
execution manager. The instance variables for 
BlockEditor are: 

form: contains the current form of the cursor, 
tool: if the block editor is in a mode (for 
xample, adding inputs), this contains the symbol 
for the method to execute when the red button is 
clicked. Usually it is nil. 

currentSel: contains the currently selected block 
or connection. 



3.1.3 BlockEditorView 

BlockEditorView class Is the view for Universe 
and BlockEditor. It handles all the display activity 
for the block editor. BlockEditorView is a fairly 
standard view, and has no instance variables. 



3.1.4 BlockUstController 

BlockList Controller is the controller for the 
resource list pane. The only reason for its exis- 
tence is the addition of the resource list pane 
yellow button menu. 



3.1.5 BlockUstView 

This is the view for the resource list pane, ft is 
only used because the standard SelectionlnList- 
View pluggable view does not understand the 
broadcast messages from class Universe. 



3.1.6 Block 

The Block class manages all the logical data 
for each block. The instance variables for Block 
are: 

inputs: an OrderedCoflection of the block input 
names. This list has a one-to-one correspondence 
with the inputs instance variable in class Dis- 
playBlock. 

outputs: like inputs, except deals with the block 
output names. 

name: the name of the block. The displayBbck 
label is derived from name. 

function: the name of the BLOSIM star routine 
associated with this block. 

parameters: an Array containing the block's 
parameters. 

insidelnfo: a pointer to a user-viewabl informa- 
tion about this block; presently limited to Sch mat- 
ics. 



3.1.7 Display Block 

The nisnlayBlock class manages all the data 
relating to the display of the block. The instance 
5 variables for DIsplayBlock ar : 

position: the location of the upper-left hand 
comer of the block in the BlockEditor view. 

form: a copy of the block's form; needed 
because not all blocks are the same size. 
w extent the block's size. 

myBlock: a pointer to the displayBlock's block, 
inputs: an OrderedCoflection of the points 
representing the block's inputs, sorted in y order, 
outputs: an OrderedCollection of the points 
75 representing the block's outputs, sorted in y order. 

label: a DisplayText representation of the 
displayBlock's name. 

in put Extent, outputExtent, labelExtent each 
extent represents the minimum extent the dis- 
20 playBlock can be and still be large enough to 
display the inputs, outputs, and label, respectively. 
The actual extent is the largest of the three. 

parameters: points to the blockParams for this 
displayBlock. 

26 

3.1.8 Connection 

The connection class maintains the information 
so relating to the connections between blocks. The 
instance variables for Connection are: 

from Block: the name of the block from which 
the connection is coming. 

blockOutput the name of the specific output of 
35 fromBlock from which the connection is coming. 

toBlock: the name of the block to which the 
connection is going. 

blocklnput the name of the specific input of 
toBlock to which the connection is going. 

40 

3.1 .9 DlspiayConnection 

The DisplayConnection class, a subclass of the 
45 standard Smalltalk class LinearFit, handles the data 
related to the actual display of a connection. Most 
of the data storage and display is dealt with in 
LinearFit The only instance variable is: 

myConnection: pointer to the connection asso- 
50 dated with the displayConnection. 



3.1.10 Galaxy 

55 The Galaxy class maintains the information 
about macros. It is a subclass of Block. Instance 
variables of Galaxy are: 

blocks: a dictionary of th blocks that constitute 
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the galaxy. It is organized exactly lik the blocks 
dictionary in Universe. 

connections: a dictionary of ail th connections 
internal to th galaxy. It is rganized exactly lik 
the connections dictionary in Universe. 

ioConnections: an Ordered Collection of the 
inside-to-outside connections of the galaxy which 
maps block inputs and outputs to the macro dia- 
gram's inputs and outputs. 



3.1.11 DispIayGalaxy 

The DispIayGalaxy class is a subclass of Dis- 
playBlock. The only difference between a dis- 
playBlock and a displayGalaxy is that a dis- 
playGalaxy has a patterned fill. It has no instance 
variables. 



32 Classes Supporting Block Parameterization 

The block editor has a number of support 
classes which manage block parameter acquisition, 
as shown in F1C. 3b; The actual parameters for 
each block are created when the corresponding 
displayBlock is labeled for the first time. The user 
is prompted to substitute the parameters for items 
in a list as described in Section 2.2.11. This builds 
a template that is used to build the formRlloutView 
whenever "set parameters" is selected from the 
block menu. The parameter instance variable in the 
display Block points to the blockParams for that 
block. 



3.2.1 BlockParams 

BlockParams contains the template of ques- 
tions and default answers used to build the formRI- 
lout for the block parameters. More than one dis- 
playBlock can have a formFillout on the display 
screen at the same time, allowing the user to edit 
them concurrently. When "accept" is received by 
the formFillout.it sends the blockParams the mes- 
sage "finishUp." The blockParams then stores the 
new parameter values into the template and sends 
the new parameter values to the displayBlock. The 
instance variables for BlockParams are: 

template: an OrderedCollect'on of three-element 
OrderedCoilections. Each three-element ordered- 
Collection represents one parameter. The first ele- 
ment is a string containing the parameter name, 
such as ■risetime 1 or'units.'. The second element is 
the default answer (for single-valued parameters) or 
an array of strings (for buttons as shown in RGS. 
14 and 15). The second element could contain 
values such as '1.5* or ('RAD' 'GRAD' 'DEGREE 1 ). 



The third element is the current answer, such as 
'IT or 'DEGREE., The arrow after the parameter 
name in the formFillout is added during the cre- 
ation of the formFillout 

5 showDefaults: a Boolean, which if true, will show 
the default answer, and if false, will show the cur- 
rent answer. 

ansOC: anOrderedCollection used in the Block- 
Context which is executed when the formFillout is 

10 accepted. The new parameters are stored into an- 
sOC. 

displayBlock: points back to the displayBlock 
associated with this blockParams. 

75 

3.2.2 FormFillout 

FormFillout a subclass of standard Smalltalk 
class FiillnTheBlank, takes a collection of questions 

20 and answers and prompts the user to edit the 
answers. The user then accepts the answers, 
whether or not any editing has taken place. This 
closes the formRlloutView. FormRIIout is the 
model for FormRlloutView and FormRIIout Control- 

25 ler. The instance variables for FormRIIout are: 

okayToLeave: a Boolean which is true if the 
formRllout is scheduled, false if the formRIIout has 
control. 

BlockParam: points back to the blockParams 
30 which invoked this formRIIout This is used to 
determine where to send the new parameters. 



3.2.3 FormRIIoutControlter 

35 

FormRlloutController is the controller for Form- 
RIIout It waits for an accept message, and then 
tells all the subcontrollers to perform their accept 
actions. It has no instance variables. 

40 

3.2.4 FormRlloutView 

FormRlloutView is the view for FormRIIout It is 
45 a subclass of RIHnTheBlankView. FormRlloutView 
builds the view and starts up the controller. A 
formRlloutView consists of messageView-answer- 
View pairs, which are basically filllnTheBlankVlews 
displayed horizontally instead of vertically. The but- 
50 tonViews are a group of OneOnButtons with a 
ValueHoIder as their connector. FormRlloutView 
has no instance variables. 
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3.2.5 HorizFilllnTheBlank, HorizFilllnTheBlankView, 
SimpleMinded-Controller 

These three classes make up a FilllnTheBlank 
that is displayed horizontally instead of vertically. 
They are used in the FormRIIoutView. 



3.2.6 Template 

Template is used by BlockParams to get the 
question/default answer pairs. The instance vari- 
ables for Template are: 

text the string that the user edits to create the 
question/default answer pairs. The resulting array is 
returned to BlockParams. 



3.2.7 ValueHolder 

ValueHolder is used to store the value of the 
currently selected button (e.g., 1 =sine, 2= square, 
3= triangle in parameter view 168 in FIG. 14). 
When the ValueHolder receives the accept mes- 
sage from the formFilloutController. it sends that 
value to be stored in blockParams. The instance 
variables for ValueHolder are: 

value: the label of the currently selected button. 

acceptBlock: the BlockContext evaluated by the 
valueHolder upon receiving the accept message. 



3.3 Additional Support Classes 

The block editor has three additional support 
classes which deal with XY-scrolling and aligning 
the BlockEditor view on a grid. 



3.3.1 XAxisScroIlController 

XAxisScrollControfler represents control for 
scrolling using an x-axis scroll bar. It is a subclass 
of Scroll Controller which creates an x-axis scroll 
bar. The x-axis scroll bar is controlled in a manner 
analogous to the y-axis scroll bar. The instance 
variables for XAxisScroIlController are: 

xZcroilBar: inside white, the outer rectangle. 

xMarken inside gray, the inner rectangle. 
xSavedArea: the area the xScrollBar overlaps, 
restored whenever the xScrollBar is hidden. 



3.3.2 GriddedTopView 

GriddedTopView forces the BlockEditor vi w to 
always be aligned on a 6x6 grid. This is done by 
s modifying the method getFrame. It eliminates the 
problem of moving or collapsing and reopening a 
block editor and being unable, to draw straight 
. lines. GriddedTopView has no instance variables. 

TO 

3.3.3 GriddedTopViewController 

GriddedTopViewController modifies the 
blueButton messages "close - and "move." The 
is change to close adds a confirmer to forestall pre- 
mature closing of a block editor. The change to 
move forces the BlockEditor view to always align 
on a 6x6 grid. 

GriddedTopViewController has no instance van- 
20 ables. 



3.4 Internal Structure of the Block Editor 

25 RGS. 31 through 41 illustrate the state diagram 

of the Block Diagram Editor. The states of the 

system primarily change as a result of mouse 

movements and button presses. 

Referring to the Main Control Loop State Dia- 
so gram (FIG. 31), the editor is started up by issuing 

the Smalltalk statement 

BlockEditor openGn: (Universe new) 

The block editor is started with ail parameters set 

to their initial states. The Universe instance van- 
35 ables are set to: 

blocks: empty dictionary 

connections: empty dictionary 

savedBIocks: CannedBlocksList 

dataDisplays: empty dictionary 
40 listlndex: nil 

onGalaxy: false 

currentGalaxy: nil 

model Ptn nil 

The BlockEditor instance variables are initialized to: 

45 form: arrow cursor form 
tool: nil 
currentSel: nil 

Next, a window 100 is created as shown in 
FIG. 7. The entries in the resource list 106 are 

50 taken from the Universe savedBIocks dictionary. 
When this window is activated (by selecting It with 
the mouse), the "Main control loop" 200 (FIG. 31) 
takes control. When in the BlockEditor window 100 
(FIG. 6), there are three areas in which mouse 

55 activity will take place: the editing pane 104, th 
resource list pane 106 and th title tab area 102. 
Moving th cursor (with the mouse) into ne of 
these areas causes the control loop state for that 
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area to be ntered, i.e., one of "Editor Pane Control 
Loop* 201, "Resource List Pane Control Loop" 202 
or "Title Tab Control Loop" 203 in FIG. 31. 

When a mouse button is pressed, the control 
state is changed to the appropriate button activity 
state, 204, 205. 206, 207 or 208. Note that the blu 
button mouse activity 206 is independent of the 
area in which the mouse cursor is positioned. The 
following paragraphs describe the activities in each 
state. 



3.4.1 Editor Pane Red Button Activity States 

While in the editor pane 106, the Red Button 
(BLOCK 204) controls the placement of blocks and 
connections in the diagram. The mouse button 
activity for this editing is shown in FIG. 32 for the 
overall activity, in FIG. 32a for drawing connections, 
in FIG. 32b for moving blocks and FIG. 32c for 
moving connections. Each activity is identified as a 
block by a reference numeral and figure number- 
(s). The blocks and connections are functionally 
identified in the drawings, and their operations are 
further described below. 



3.4.1,1 Draw block at cursor point 210 (FIG. 32) 

Drawing a block at a cursor point consists of 
taking the form (e.g., a rectangle) specified by 
DisplayBlock form and placing it at the cursor 
location. 



3.4.1 .2 Selecting/highlighting and 

deselecting/dehighiighting blocks 211, 212 (FIG. 
32) 

Block selections are identified internally by the 
cursor type. Selecting a block makes the cursor 
type (BlockEditor "form") that block. Similarly, de- 
selecting a block sets the cursor to the normal 
(arrow) cursor. Highlighting a block is accom- 
plished by bit-anding the pixels of the block form 
with a halftone form and displaying the result De- 
highlighting a block reverts to drawing the block in 
its normal form. 



3.4.1.3 Select and highlight connection 213 (FIG. 
32) 

Selecting a connection set the cursor type 
(BlockEditor "form") to the connection. The con- 
nection is highlighted by anding the solid line re- 
presenting the connection with a halftone form. 



3.4.1.4 Draw connection 214 (FIGS. 32, 32a) 

The draw connection state 214 is entered by a 
single click of the mouse button on an unconnec- 
5 ted output A new instance of Connection is cre- 
ated with the instance variables set to: 
fromBlock: the block containing the output just clic- 
ked on 

blockOutput the name of the output just clicked on 
10 toBlock: nil 
blocklnput nil 

Also a new instance of displayConnection is cre- 
ated and Initialized to: 
collectionOfPoints: empty list 

is myCormection: pointer to the just-created Connec- 
tion instance. 

A connection is constructed by moving the 
mouse (state 220) and clicking at desired locations 
(states 221, 222) to change the direction of the line. 

20 The location on the diagram of each of these 
boundary points Is added to "collectionOfPoints." 

This process continues until an unconnected 
input block pad is reached (state 223) or another 
output or connected input pad is reached (state 

25 224). When an unconnected input is reached, 
"toBlock" is set to the block containing the input 
and "blocklnput" is set to the name of the input 
The displayConnection object is added to the Uni- 
verse "connections* dictionary. 

30 

3.4.1.5 Move block 216 (FIGS. 32, 32b) 

The move block state 216 is entered when the 
35 mouse button is depressed within the cursor in a 
block and the cursor is moved while the button is 
depressed. The block is continuously redrawn fol- 
lowing the cursor while the button is depressed 
(state 225). If the button is released while the 
40 cursor is in editor pane 104, the block is drawn one 
last time at the current cursor position (state 227), 
any connections to the block are redrawn (state 

228) and block data base is updated to show the 
new position of the block by setting DisplayBlock 

45 "position" to the coordinates of the current mouse 
position. If the button is released with cursor out- 
side the editor pane, the block is deleted (state 

229) and the connections to the block are deleted 
(state 244). 

50 

3.4.1.6 Move connection 218 (FIGS. 32, 32c) 

The move connection state 218 is entered 
55 when the cursor is depressed on a connection and 
th cursor moved while the button is depressed. 
There are two types of connection moves: moving 
the output end of the connection (state 230) and 



19 



37 



EP 0 295 760 A2 



38 



moving the input end of the connection (state 231). 
Both operate in a similar manner in that while th 
button remains depress d the connection line is 
continuously updated to follow the cursor (states 
232 or 239) . Where the cursor is located when the 
button is released determines the final state en- 
tered for moving the connection. When moving the 
input end of the connection, the final cursor loca- 
tion must be on an unused input pad (state 238) to 
successfully move the connection. Similarly, when 
moving the output end of the connection, it must 
terminate on an unused output pad (state 233) . If 
the button is released with the cursor outside the 
editor pane, the connection is deleted (state 236). 
Any other termination point results in an error (state 
234, 235, 237) and the connection is unchanged. 

Once a new location has been successfully 
identified, the Connection instance variables 
"fromBlock." "blockOutput," "toBlock" and 
"blocklnput" are updated to reflect the changes 
made. 

3.4.2 Editor Pane Yellow Button Activity States 
205 is further detailed in FIG. 33. 

While in the editor pane 106, the yellow but- 
ton's control depends on where in the editor pane 
the cursor is. The activity is split into four possible 
states which depend on the mouse position and 
how the block editor was opened. These state 
transitions are: cursor inside a block (state 240), 
cursor inside a macro (state 241), block editor open 
on a macro and cursor outside a block (state 242), 
and block editor open on a top level diagram and 
cursor outside a block (state 243). 



3.4.2.1 Block Menu Activity 

The Block Menu Activity state 240 (FIG. 34) is 
entered from state 205 whenever the cursor is in 
the editor pane and Inside a block and the yellow 
button is pressed. Entering this state brings up a 
pop-up menu 116 as shown in FIG. 13. Selecting 
one of these menu items enters a new state as 
shown in FIG. 34. Three of these states deal with 
processing the inputs to blocks and are further 
expanded in FIG. 34a. Also three of these states 
deal with block outputs and are further expanded in 
FIG. 34b. These other states are described as 
follows: 



Convert block internal form to macro internal form 
252 (FIG. 34): 

A new instance of Galaxy is created with the 
following instance variables set to: 
Galaxy inputs: set to Block inputs 
outputs: set to Block outputs 



name: Block name 
function: nil 
parameters: nil 
insidelnfo: nil 

5 this is followed by creating a new instance of 
DisplayGalaxy and copying the DisplayBlock in- 
stance variables to the DisplayGalaxy instance vari- 
ables. The Universe "blocks" dictionary is updated 
by replacing the Block that was changed to the 

io new Galaxy. 



Invoke internal editor block 254 (FIG. 34): 

15 If the Block "insidelnfo" instance variable is not 
nil, then the object this variable points to is called 
with the message "edit" It is assumed that any 
objects placed here know how to edit themselves. 

20 

Invoke parameter form fillout pane 251 (FIG. 34): 

When the "set parameters" menu Item is se- 
lected, the DisplayBlock "parameters" object (an 
25 instance of BlockParams) is given control to dis- 
play and allow the user to edit the parameters. 
Upon "accepting" the modified parameters, a new 
list of current values is generated and stored in the 
Block "parameters" Instance variable. 

30 

Define internal block functions 253 (FIG. 34): 

Prompts for the name of the star routine to be 
35 called by BLOSIM when this block executes. The 
name of this star function is stored in the Block 
"function" instance variable. 



40 Add an input to block 245 (FIGS. 34, 34a): 

The cursor is changed to an input symbol and 
tracks the mouse until the red button is clicked 
inside a block (state 255) . The input node is added 

45 to the ordered collection for Block "Inputs" and 
DisplayBlock "inputs." The DisplayBlock 
"inputExtent" is recomputed to insure sufficient 
size is available to display the additional input The 
block is then redrawn with the additional input 

so added (state 256). 



Remove an input from block 246 (FIGS. 34, 34a): 

55 The cursor is changed to an input symbol with 
a superimposed X and tracks the mous until th 
red button is clicked on an input symbol (state 
257). The selected input node is removed from th 
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ordered collection for Block "inputs" and Dis- 
playBlock "inputs/ The DisplayBlock "inputExtent" 
is recomputed t possibly reduce the size of the 
display d bl ck. The block is th n r drawn with the 
input removed (state 258). 



Label an input 247 (FIGS. 34, 34a): 

The cursor is changed to the label input 
prompt and tracks the mouse until the red button is 
clicked on an input symbol (state 259) . The user is 
prompted for a new name and the name of the 
symbol is changed (state 260). The name of the 
symbol is changed by modifying the name in the 
ordered collection associated with the selected in- 
put node for the Block "inputs" instance variable. 



Add an output to block 248 (FIGS. 34. 34b): 

The cursor is changed to an output symbol and 
tracks the mouse until the red button is clicked 
inside a block (state 265). The output node is 
added to the ordered collection for Block "outputs" 
and DisplayBlock "outputs." The nisplayBlock 
"outputExtent" is recomputed to insure sufficient 
size is available to display the additional output 
The block is then redrawn with the additional out- 
put added (state 266). 



3.4.2.2 Macro M nu Activity 241 (FIGS. 33. 35) 

The macro menu activity state 241 is entered 
when the cursor lies within a macro block instead 

5 of a normal block. Entering this state brings up a 
one item pop-up menu for entering the macro. If 
this item is selected, a block diagram editor is 
invoked on a copy of the macro, (state 272). After 
making changes to the macro with the editor, the 

ro user "accepts" the changes with the yellow button 
in the editor pane, which causes the copy of the 
original macro to be saved as the macro (described 
in the macro BlockEditor menu activity in FIG. 36). 
The macro block editor is then closed with the blue 

75 button pop-up entry "close." 

In invoking the block editor on the macro, the 
macro must first be converted to the object Uni- 
verse. This is done by creating a new instance of 
Universe with the instance variables set to; 

20 blocks; copy of the Galaxy blocks dictionary 

connections: copy of the Galaxy connections dic- 
tionary 

dataDisplays: dictionary of block name in the 
macro 

25 savedBlocks: CannedBlocksUst 
listlndex; nil 
onGalaxy: true 

currentGalaxy: pointer to the current macro being 
expanded 

so modelPtn pointer to parent Universe 



Remove an output from block 249 (FIGS. 34, 34b): 

The cursor is changed to an output symbol 
with a superimposed X and tracks the mouse until 
the red button is clicked on an output symbol (state 
267). The selected output node is removed from 
the ordered collection for Block "outputs" and Dis- 
playBlock "outputs." The DisplayBlock 
"outputExtent" is recomputed to possibly reduce 
the size of the displayed block. The block is then 
redrawn with the output removed (state 268). 



Label an output 250 (FIGS. 34, 34b): 

The cursor is changed to the label output 
prompt and tracks the mouse until the red button is 
clicked on an output symbol (state 269). The user 
is prompted for a new name and the name of the 
symbol is changed (state 270). The name of the 
symbol is changed by modifying the name in the 
ordered collection associated with the selected out- 
put node for th Block "outputs" instance variable. 



3.4.2.3 Macro BlockEditor Menu Activity 242 (FIGS. 
33. 36) and BlockEditor Menu Activity 243 (FIGS. 
35 33, 37) 

The BlockEditor Menu Activity states 242 and 
the Macro BlockEditor Menu Activity states 243 are 
nearly identical. The "Execute diagram" state 285 
40 in the BlockEditor Menu Activity (FIG. 37) is re- 
placed with the "accept" 279 and "cancel" 280 
states (FIG. 36). The activities that are common to 
both states 242, 243 are first described, followed 
by the dissimilar activities. 

45 

Create macro block 275 (FIGS. 36, 37, 37a): 

Referring to FIG. 37a f the cursor is changed to 
50 a spiral (state 290) and a new instance of a Galaxy 
is created with instance variables (blocks, connec- 
tions and ioConnections) set to nil. Blocks to be 
included in the macro are selected and added to 
the Galaxy "blocks" instance variable (state 292, 
55 294). Once the sefecti n process is complete (i.e., 
double click not inside a block) the connections 
between selected blocks ar transferred to the Gal- 
axy "connections" dictionary and connections be- 
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tween macro blocks and other blocks are trans- 
ferred to the Galaxy "ioConnections" dictionary. 
The selected blocks and associated connections 
are deleted from the Universe "blocks" and 
"connections" dictionary (state 295). A name for 
the macro is obtained from the user (state 296) and 
stored in the Galaxy "name" Instance variable. The 
user then positions the macro in the editor pane 
(state 297). The macro is then added to the Uni- 
verse "blocks" dictionary. This operation is fol- 
lowed by reconnecting the connections between 
external blocks and the macro, (state 298) and then 
resetting the cursor to normal mode (state 299). 



Label block 276 (FIGS. 36, 37 t 37b): 

Referring to FIG. 37b, upon entering state 276, 
the cursor is changed to "Label which block" (state 
300). A loop is entered until the user selects a 
block (state 301). At the prompt for the new label 
(state 302), the new label is read. 

If this is the first time the block has been 
labeled (i.e., it is a new block), then the block 
parameters are prompted for. An array of strings is 
displayed in an editing window in which standard 
Smalltalk editing facilities are used to construct a 
list of parameters and their initial values. A simple 
template is used for the parameter name and de- 
fault value (see Section 3.2.1). Upon completing 
the parameter definitions, a new instance of Block- 
Params is created vith: 
template: set to the user generated list 
displayBlock: points to the DisplayBlock in which 
these parameters are, associated 

The DisplayBlock "parameters" instance vari- 
able is loaded with a pointer to this instance of 
BlockParams. The Block "parameters" instance 
variable is loaded with the default parameter val- 
ues. 

From the new block label a new DisplayBlock 
"labelExtent" is computed. The displayBlock extent 
is then set to the maximum of "inputExtent," 
"outputBctent" and "labelExtent" The block is then 
redrawn at its current position. 



Add new block 277 (FIGS. 36, 37, 37c): 

Referring to FIG. 37c. in state 277, a new 
instance of Block and DisplayBlock are created 
with the instance variables set to the following: 
Block inputs: empty ordered collection 
outputs: empty ordered collection 
name: nil 
function: nil 
parameters: nil 
insidelnfo: nil 



DisplayBlock 
position: nil 

form: default rectangle 
extent default size of block 
5 myBlock: pointer to just created Block 
inputs: empty ordered collection 
outputs: empty ordered collection * 
label: nil 

inputExtent default size of block 

10 outputExtent default size of block 
labelExtent default size of block 
parameters: nil 

The cursor is changed to an unlabeled rectan- 
gle (state 305) and tracks the mouse until the red 

75 button is clicked. If there is no space for the block, 
an error message is issued and the process re- 
peated (state 306). If there is space available for 
the block, it is placed at the current location (state 
307) and the DisplayBlock "position" is set to the 

20 current cursor location. This newly created block is 
added to the "blocks" dictionary for the Universe 
and the DisplayBlock is added to "dataDisplays" 
- dictionary for the Universe. 

The display block form, size and appearance is 

25 determined from the number of inputs, the number 
of outputs and the label. The size of the form is 
always adjusted so that sufficient room exists for all 
inputs to neatly fit on the left edge of the block, all 
outputs to neatly fit on the right edge of the block 

30 and the label to be centered in the block. Any time 
the number of inputs, number of outputs or the 
label is changed, the DisplayBlock "Extent" is de- 
termined from the maximum of the "inputExtent" 
"outputExtent" and "labelExtent" A new Dis- 

35 playBlock "form" is created with a rectangle drawn 
within it the label property centered and all Inputs 
and outputs evenly spaced on the form. 



40 Cancel current mode and restore arrow cursor 278 
(FIGS. 36. 37): 

In state 278, the current mode is canceled by 
deselerting any blocks by setting Universe 
45 "listlndex" to nil. The cursor is set to normal 
(arrow) by setting BlockEditor "form" to the arrow 
cursor. 



50 Make changes since last "accept" permanent 279 
(FIG. 36): 

In state 279, changes to a macro are made 
permanent by selecting the "accept" yellow button 
55 Macro BlockEditor Menu item. When this action is 
invoked, information in the macro (Galaxy) pointed 
to by Universe currentGalaxy is updated to: 
Galaxy blocks: set to a copy of current Universe 
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blocks 

Galaxy connections: set to a copy .of current 
<Universe connections 

Galaxy ioConnections: set to an ordered collection 
of the current unconnected inputs and outputs. 

Delete changes since the last accept 280 (FIG. 36): 

in state 280, changes made to a macro while in 
a block editor can be canceled by selecting the 
"cancel" yellow button Macro BlockEditor Menu 
item. When this action is invoked, information in 
the current Universe is reset to the macro (Galaxy) 
information pointed to by currentGalaxy in the fol- 
lowing manner 

Universe blocks: copy of the Galaxy blocks dic- 
tionary 

Universe connections: copy of the Galaxy connec- 
tions dictionary 

Display labels on inputs and outputs 281 (FIG. 36, 

In state 281. for each block in the Universe 
"blocks" dictionary, the name of each block input 
(from Block "inputs" ordered collection) and output 
(form Block "outputs" ordered collection) is dis- 
played next to the block input and output locations 
on the display. 



Redraw entire diagram 282 (FIGS. 36, 37): 

Erases the BlockEditor pane, then displays 
each block in the Universe "blocks" dictionary fol- 
lowed by a display of each connection in the 
Universe "connections" dictionary. 



Erase entire diagram 284 (FIG. 36, 37): 

The BlockEditor pane is erased followed by 
setting the following Universe instance variables: 
blocks: empty dictionary 
connections: empty dictionary 
dataDisplays: empty dictionary 
listlndex: nil 



Execute the diagram 285 (FIG. 37, 38): 

The operation of state 285 is described in 
Section 4.0. 



3.4.3 Blue Button Activity 206 (FIGS. 31, 39) 

This activity is the conventional blue button 
activity for Smalltalk windows. 



3.4.4 Resource List Pane Yellow Button Activity 
207 (FIGS. 31,40) 

io Referring next to FIG. 40, when in the Re- 
source list pane 106, pressing the yellow button 
menu brings up a pop-up menu. The pop-up menu 
has one entry In it: "remove entry." Selecting this 
entry and releasing the mouse button will cause a 

is selected item in the resource list to be removed. If 
no item is selected, then the action is ignored. 
Removing an item from the resource list is accom- 
plished by deleting the selected item from the 
dictionary in the Universe saved Blocks instance 

20 variable. Once it is deleted, the modified list is 
redisplayed. 



3.4.5 Resource List Pane Red Button Activity 

25 

Referring to FIG. 41, while in state 208 the red 
button is used to select items in the resource list 
for placement in the editor pane 106. When an 
item is selected (state 330), the following informa- 
30 tion is established: 

Universe listlndex: set to the index of the selected 
menu item 

BlockEditor form: set to the form of the block from 
DisplayBlock of the selected block 

35 Similarly, if a item is de-selected (state 332): 
Universe listlndex: set to nil 
BlockEditor form: set to the normal (arrow) cursor 
The Smalltalk environment provides the basic 
methods needed to highlight items in the resource 

40 list (state 331). 



4.0 COMPONENTS OF THE EXECUTION MAN- 
AGER 

45 

This section describes the major components 
of the execution manager in greater detail with 
reference to FIGS. 3, 3c and 4. Referring first to 
FIG. 3c, the execution manager consists of several 
50 major components. Beginning at "execute dia- 
gram" block 350, these are: 

The diagram scanner 352 - which reduces the 
program represented by a block diagram to a net- 
list of blocks and connections. 
55 The netiist interpreter 354 - which reads the 
netlist and executes its meaning. 

The block functions 368 - which implement the 
meaning of the blocks in a block diagram. 
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The server/display controller 362 - which moni- 
tors and handles the interprocess communication 
from the block functions to the Smalltalk process, 
storing and retrieving information in display mem- 
ory 86. 

The data display objects (see FIG. 3) - which 
receive and display data that is channeled through 
the server 362 from memory 86. Although the data 
display objects are created and managed by the 
execution manager, they may alternatively be clas- 
sified as components of the user interface, as 
shown by blocks 85, 89 and 91. 

The diagram animator - which binds the actual 
execution of a block function with the display of a 
given block in a diagram. This function, whose 
operation is shown in FIG. 4, is embedded in 
server 362 and block 85. 

These major components are described below. 



4.1 The Diagram Scanner 

The diagram scanner 352 is initiated when the 
'execute diagram" pop-up menu item is selected 
from the block editor's middle mouse button menu. 
The menu selection results in a call to the Bloc- 
kEditor method or routine executeOiagram which 
initiates an execution cycle. First, the block dia- 
gram is checked for validity. A diagram is consid- 
ered valid if all block inputs and outputs are prop- 
erly connected. If all blocks are not properly con- 
nected, an error message is displayed on the 
screen and the execution cycle is terminated. 

If the current diagram is valid, the execution 
cycle continues. At this point the C process (which 
contains the netlist interpreter and the block func- 
tion code) is forked as a child process of the 
Smalltalk process and the two interprocess com- 
munication channels (pipes) are established. One 
pipe 98 is used for the Smalltalk process to send 
information (netlist etc.) to the C process and the 
other pipe 99 enables information transfers from 
the C process to the Smalltalk process. 

Once the communication channels are estab- 
lished, the mainline of the recursive diagram scan- 
ner 352 (BlockEditor method expandMacro) is 
called. The term "macro" is used to denote a 
collection of connected blocks represented as a 
single block. The expandMacro method creates the 
netlist by recursively expanding the internal struc- 
ture of each of the blocks in a diagram. The 
recursion, in effect "flattens out" a sequence of 
possibly nested macros into a list of block func- 
tions and their connections. Since a complete block 
diagram can be thought of as a single block, th 
data structures constituting the entire block dia- 
gram are sent to expandMacro to begin the expan- 
sion. 



The internal structure of the expandMacro 
method is as follows. First each block in th inter- 
nal structure of the block being expanded is exam- 
ined. If it is a macro itself, a recursive call is made 

5 to expandMacro to expand its internal structure. If 
not the block represents a single block function 
and information about the block is sent down the 
pipe 98 to the netlist interpreter. The information 
sent is the block's name (same as its label in the 

70 diagram), the block's function (a string that informs 
the interpreter which block function to execute on 
the block's behalf) and the static parameters of the 
block (e.g., dc offset frequency, etc. for a sinewave 
generator block). 

is When all the block information for a particular 
level of recursion has been sent information cor- 
responding to the connections of the blocks (at this 
level of recursion) is sent to the interpreter. Each 
connection is described by the names (labels) of 

20 the blocks at either end (as seen on the diagram) 
and the labels of its input and output The descrip- 
tion of the connections of the current macro with 
the previous level in the recursion is the last in- 
formation sent for the given level. 

25 The keyword "END" is sent to the interpreter 
when the complete netlist for each expanded 
macro has been sent When the "END" corre- 
sponding to the entire diagram has been sent, the 
netlist expansion is complete. At this point there is 

so a return from the original call to expandMacro and 
the execute Diagram method once again has con- 
trol. Its last action is to call the BlockEditor method 
server, which will monitor communications via pipe 
99 from the C process. A description of the server 

35 follows the description of the netlist interpreter and 
the block functions. 



42 Netlist Interpreter and Block Functions 

40 

The netlist interpreter 354 provides the ability 
to execute the meaning of a netlist It is essentially 
a control program that schedules, executes and 
monitors the execution of the block function ap- 

45 plication code. 

The interpreter is based on the block simula- 
tion program called IBLOSIM (for Interactive BLOck 
SIMulator) which is built up around the block sim- 
ulator (BLOSIM) program developed at U.C. Berke- 

50 ley by David Messerschmrtt BLOSIM, indicated in 
FIG. 3c by block 356, requires that the topology 
and block parameters be specified at compile time. 
Each time a change is needed in the topology, a 
s urce code file must be edited, recompiled and 

55 re-linked into an executable module. In contrast 
IBLQSIM allows specification of the topology and 
parameters as a stream of ASCII text i-e. a netlist 
As used in the netlist interpreter, IBLOSIM in- 

24 



47 



EP 0 295 760 A2 



48 



eludes a module 354 which reads a stream of 
ASCII text describing the diagram's topology and 
block parameters and makes this information avail- 
able to BLOSIM for establishing the required inter- 
nal topology. It also includes driver modules 366 
that read in and interpret parameters for each 
block, thus preparing function calls for the block's 
execution by BLOSIM. Changing the topology or 
parameters only requires construction of the appro- 
priate text stream or netlist Recompilation or relin- 
king of a source code file to form an executable 
module is unnecessary. 

The block functions 368 contain the application 
code for each block and are equal to "stars" in 
BLOSIM terminology. A macro (called a "galaxy" in 
BLOSIM terminology) is therefore represented by 
one or more block functions. More specifically, a 
block function is unique data space for information 
about a particular block and the C code that imple- 
ments its functionality. The C code includes the 
"block function driver routine" and the "block func- 
tion routine." A listing of a typical block function 
appears in APPENDIX F and descriptions of the 
block functions available in the resource list pane 
106 are contained in TABLES 1, 2 and 3. 

The interpreter 352 reads the block name, 
function and connection information sent by the 
diagram scanner 352. The first time each block 
name is encountered, a block function is created 
by block initialization procedure 358. This proce- 
dure sets up a data field in data storage 94 for the 
called block function, the code for which is stored 
in block 368. The interpreter passes control to the 
corresponding block function driver routine, which 
is responsible for allocating the data area for this 
block function and reading and storing any param- 
eters that may follow in pipe 98. When the driver 
exits, it returns control to the interpreter to read 
more block names or connection information. 

After all the blocks in the diagram are pro- 
cessed, the interconnections are processed by 
"generate connection list" block 360. This proce- 
dure uses the netlist interconnect information to 
define data flow channels between the data fields 
set up in the execution data storage 94. 

When the netlist has been completely pro- 
cessed, the interpreter 354 schedules and executes 
the application through BLOSIM 356. It continues 
to pass control to the various block function rou- 
tines until the execution is complete. 

Referring to FIG. 4, as the block functions 
execute, they may communicate, via the pipes 98 
and 99, with the Smalltalk process. This is done by 
message server/display controller 362 (RG.3c), 
which includes interface software to communicate 
between the C process and the Smalltalk process. 
The interpreter itself sends some m ssages to the 
Smalltalk proc ss directly. The legal data and m s- 



sage transfers are each described below. The ac- 
tion taken by the Smalltalk process upon receipt of 
each message is discussed in detail in the next 
section. 

5 All current block functions request that their 
corresponding display block in the block diagram 
be set to reverse video while they execute. 
BLOSIM 356 notifies the message server/display 
controller 362 when a block function is about to 

10 commence execution, and again when it is finished. 
The keyword "invert" is sent to the Smalltalk pro- 
cess by each block function along with the display 
block's name. The server/display controller 362 
channels this request to the display block code that 

15 performs the "inversion." The inversion code re- 
sponds by sending the block function a signal (the 
character '@') that the display block has been 
inverted, at which point the block function contin- 
ues executing. 

20 An error may occur during the execution of a 
block function. The block function can report the 
error by sending the keyword "error" to the Small- 
talk process followed by an error message. The 
server intercepts "error" and causes the message 

25 to be displayed. 

Various block functions also report the results 
of an execution. These results typically take two 
forms. One form is a waveform (essentially as an 
array of elements). A block function may con- 

30 ununicate a waveform to the Smalltalk process by 
sending the keyword "graph" down pipe 99. The 
server reads this , and enables an appropriate data 
display object to read additional data from the 
block function, including values that parameterize 

as the waveform data (scale factors, units, etc.) and 
the waveform data itself. 

The keyword "digitizer" can also be used to 
send a waveform to the Smalltalk process. This 
keyword produces similar results to "graph," but 

40 can be manipulated during execution to modify the 
acquisition window of data returned, as described 
above. 

The other form is a scalar value (such as a 
waveform maximum value). A block function can 

45 send a scalar to the Smalltalk process by sending 
the keyword "scalar" down the pipe 99 followed by 
the value to display. The server/display controller 
362 again reads the keyword and a data display 
object is caused to display the value. 

so As mentioned above, the interpreter also talks 
directly to the Smalltalk process. This communica- 
tion is necessary to implement the animation of 
"macro" display blocks as further discussed in the 
next section. 

55 
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4.3 The Server/Display Controller, the Data Display 
Objects and Diagram Animator 

The server/display controller 362 (or simply 
"server") is the portion of the Smalltalk process 
that handles all transmissions from the C process. 
As mentioned above, the server is given control 
when the diagram scanner has finished sending the 
netlist to the interpreter. The server recognizes and 
acts upon the following keywords: "graph," 
"scalar," "error," "digitizer, " "invert," "disarm" and 
"arm". 

The keywords "invert," "arm" and "disarm" all 
pertain to diagram animation. The server reads the 
"invert" keyword followed by the name of the block 
within the block diagram that is to be set to reverse 
video. The BlockEditor method invertDisptayBlock 
performs the actual inversion. When read by the 
server, the keyword "arm" results in a call to the 
BlockEditor method armMacro. This keyword is 
also followed by the name of the block (a macro in 
this case) that is to be inverted. The next inversion 
request, from a block that is part of the internal 
structure of the currently-armed macro, is dealt 
with in a special manner by BlockEditor method 
InvertDisplayBlock. It causes the armed macro's 
display block to be animated (i.e., set to reverse 
video). Subsequent block inversion requests, from 
other blocks composing the macro, are ignored by 
invertDisplay Block until the "disarm" keyword is 
received by the server, causing a call to Bloc- 
kEditor method disarmMacro. 

The keywords "graph," "digitizer," "scalar" 
and "error" all pertain to data display objects, 
which display the various block function results to 
the user. In addition to recognizing these keywords, • 
the server is responsible for creating the data dis- 
play objects and channeling the data from the 
block functions to the data display objects. 

As a result of the diagram execution, the server 
might receive the keyword "graph" followed by the 
name of the block function that wishes to have a 
waveform displayed. The server maintains a list of 
the current data display objects in display informa- 
tion storage 86. If no data display object by that 
name exists, the server creates one and gives it 
access to the communication channel so that it can 
read the waveform data If the display object al- 
ready exists, the server simply passes control to 
the object and does not create a new one. 

The "scalar" keyword results in the same sce- 
nario as above except a scalar data display object 
is created and/or given control. 

The keyword "digitizer" (or another keyword 
corresponding to a physical instrument) accesses 
the signal viewing function 364, described in further 
detail in Section 5.0. The keyword "digitizer" acts 
like "graph" except the data display object has a 



special feature: it knows how to directly access the 
parameters of the corresponding display block in 
the original block diagram. Therefore, a block can 
be re-parameterized and the diagram re-executed 
5 without returning to manipulate the original block 
diagram. 

The "error" keyword differs from the other 
keywords in that its corresponding data display 
object (the "errorLog") is used by the entire dia- 
io gram (versus the individual block association of the 
other display objects). The server creates the 
"errorLog" when the first error message is encoun- 
tered from any block and channels ail subsequent 
error messages (from any block) to the "errorLog." 

rs 

4.4 Interprocess Communication Formats 

The interprocess communication has been de- 

20 scribed in general terms in the previous sections. 
This section describes the data communication for- 
mats in more detail. 

The block editor maintains the parameters for 
each block in a given diagram essentially as an 

25 array of strings (i.e. f character arrays). The fields of 
the block and connection data structures that are 
accessed by the diagram scanner are also strings. 
The diagram scanner currently does no conversion 
of these fields. Therefore, the entire netlist is seen 

30 by the C process as a stream of ASCII text 

The netlist interpreter and the block functions 
use standard C language I/O routines to access the 
Smalltalk-to-C pipe [The C fscanfO function is 
used]. White space characters in the pipe stream 

35 are seen as delimiters by the standard I/O routines. 
Therefore, parameters, block names, etc. may not 
contain blanks, tabs, carriage returns, etc 

ASCII transmission of waveform data to the 
Smalltalk process, however, is prohibitively slow. 

40 Therefore, Oto-Smalltalk pipe communication uses 
binary transmission for waveform data and other 
numeric values [the C fwriteO function is used for 
binary data] and uses ASCII transmission for string 
data [the C fprintfO function is used for character 

45 data]. The diagram animation handshaking is also 
currently implemented using standard I/O routines. 
Interprocess signaling is an alternative that may be 
used. 

An operative system as described above has 
50 successfully demonstrated execution of signal pro- 
cessing and data acquisition built using the block 
editor. Due to the use of BLOSIM, however, the 
multiple process, multiple language design of the 
Execution manager was, to some extent, xpedi nt 
55 rather than chosen. In addition, the functionality of 
the Execution manager (and the Experiment Man- 
ager as a whole) is currently restricted by the 
BLOSIM paradigm: an execution cycle using 
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BLOSIM is essentially a "batch" operation. Since 
the data generation capabiliti s and the data dis- 
play capabilities of the system curr ntly reside in 
separate processes, the interprocess communica- 
tion of waveform and other data is necessary and 
represents a considerable overhead. Binary pipe 
communication (versus ASCII) for interprocess 
transfers of waveform data is used to improve 
performance. 

Several design alternatives exist, however, that 
could result in further improved performance. For 
one, the display operations in the system could be 
performed directly by the block functions. The user 
interface would need to orchestrate the display, but 
waveform data transfers would be eliminated. An- 
other alternative would be a single language/single 
process port, eliminating netlist and waveform data 
transmission altogether. Waveform data areas 
could be directly accessed by all parts of the 
system. 

Additional design alternatives exist for other 
aspects of the Execution manager. The diagram 
scanner is currently activated only when a diagram 
is complete. Alternatively, the scanner could be 
active during the diagram construction phase. The 
netlist would thus be complete and ready for ship- 
ment or use when a diagram is executed. Along 
the same vein, the netlist interpreter could be re- 
placed by an incremental compiler that emits the 
necessary object code as a diagram is constructed. 
This would eliminate the interpretation phase. Or, 
the interpreter could be made to execute portions 
of a block diagram as the user is constructing 
them. This would provide the user with immediate 
feedback at each step of the construction process. 



4.5 Block Function Building Procedure and Exam- 
ple 

The next subsection describes how the general 
"star"-building techniques described in the above- 
referenced Messerschmitt BLOSIM paper have 
been modified to create the Experiment Manager's 
block functions. A C-code listing of a hypothetical 
example block function, with comments, is pro- 
vided in APPENDIX F. The example block function 
has one input and one output and does no pro- 
cessing. It shows the basic features that are com- 
mon to the Experiment Manager's block functions. 
The last subsection briefly describes the functional- 
ity of the current Experiment Manager block func- 
tions with reference to TABLES 1, 2 and 3. 



4.5.1 Building a Block Function 

The stars described in the BLOSIM paper com- 
municat values (I.e., SAMPLES) of a single simple 

5 type (type "long" integer in C terminology). The 
definition of SAMPLE was changed, for use as a 
pointer in the Experiment Manager, to be a pointer 
to a complex structure. This allows the block func- 
tions to communicate data of essentially any type 

w to each other. See APPENDIX E for the definition 
of a SAMPLE. 

The "type" field of the SAMPLE data structure 
allows each block function to check the type of the 
data it receives to verify that it is as expected. The 

75 current legal values of the SAMPLES transmitted 
can be of type "short, " "long," "int." "float," 
"double," "char *" (character string) or 
"WAVEFORM *" (pointer to a waveform) 'For the 
definition of the WAVEFORM data structure, see 

20 file "wav.h" in Appendix C of "Signal Processing 
and Display Programs" manual (TEK Part No. 070- 
616&-00), published by Tektronix, inc. (1986).1. 

The stars described in the BLOSIM paper typi- 
cally read from and write to standard text files (or 

25 stdin and stdout) . The Experiment Manager block 
functions use the pipe communication scheme de- 
scribed in Section 4.4. These block functions ac- 
cess the pipes through two global filenames de- 
fined as follows: 

30 extern RLE 'commandRIe; 
extern RLE VesponseFile; 
where "commandRIe" refers to the Smailtalk-to-C 
pipe, and "response File" refers to the Oto-Small- 
talk pipe. 

36 The user generated function "universe" in 
BLOSIM is replaced by the netlist interpreter 354 
(RQ. 3c) which reads the topology description from 
the commandRIe pipe. To properly handle star 
initialization, each star function has a star function 

40 driver routine (see "star__example" in APPENDIX 
F). The star function driver routine takes care of 
reading the parameter data over the pipe and ini- 
tializing the data storage area for the star. 

The BLOSIM stars do not need to know their 

45 names. Each Experiment Manager block function, 
however, needs access to its name in order to 
communicate effectively with the user interface 
(reverse video animation, error logging, etc.). 
Therefore, each block function stores its own name 

50 in its data area when its driver routine executes. 

Unlike the BLOSIM stars, each Experiment 
Manager block function calls the C function 
invertBlockQ to request that its display block be set 
to reverse video. Function invertBlockQ makes the 

55 reverse video request and waits for an appropriate 
signal from the Smalltalk process. The function is 
only called if the block function is about to execute 
its application code (e.g., create a waveform, ac- 
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cess and process an input, tc.). 

The BLOSIM star routines typically print error 
messages to stdout Experiment Manager block 
functions use the special errorLogO function to 
report errors to the Smalltalk process. 



4.5.2 Descriptions of Block Functions 

The majority of the Experiment Manager's 
block functions perform signal processing func- 
tions. These block functions look very much like 
the example given in the previous section except 
various calls are made to a signal processing li- 
brary approximately at the point indicated in the 
example. A brief description of these block func- 
tions is contained in TABLE 1. 

Several of the Experiment Manager's block 
functions perform instrument control functions. 
These block functions use RS-232 communications 
to talk to a GPIB controller which, in turn, controls 
the actual instruments. A brief description of the 
instrument control block functions is contained in 
TABLE 2. 

Several other block functions currently exist 
that do not fit into the above categories. These are 
described in TABLE 3. The Resource column of 
ach table refers to the names given to the blocks 
in the resource list pane of the block editor. The 
Block Function column holds the actual string used 
to name the block function and block function driv- ' 
er routines. In many cases the Resource name and 
the Block Function name are the same. Several of 
the resources have multiple rows in the Inputs, 
Outputs and Comments columns. The different 
rows refer to different alternatives. For example, the 
"add resource" in TABLE 1 accepts three alter- 
natives for its inputs and has corresponding output 
and comment fields. It accepts two waveforms as 
inputs or two scalars as inputs or a waveform as its 
first input and scalar as its second input 



5.0 SIGNAL VIEWING CONTROL 



5.1 Functional Overview of Digitizer Control 

Referring to FIG. 42, the system of FIG. 5 is 
illustrated in a functional block diagram to show 
digitizer, data flow and display screen operation 
during signal viewing control. When actuated with 
initial or default settings, the digitizer 74 receives 
an electrical signal in analog form from a device 
under test 76. The digitizer conventionally digitizes 
the analog signal and transmits raw digital data via 
communication path 502 to the digitizer driver 504. 



Path 502 comprises the thre communications ele- 
ments illustrated in FIG. 5. Raw digitizer data flows 
over tho GPIB bus 66 to the transmission protocol 
converter 64. The raw data is transmitted over the 

s RS-232 bus 62 to workstation 54. 

Returning to FIG. 42, the digitizer driver con- 
verts raw data to time/voltage coordinates. Within 
workstation 54, programming, described In further 
detail below, performs a windowing transform, in- 

ro dicated by functional block 506, which transforms 
the data from time/voltage coordinates into screen 
coordinates. This data is then transferred as in- 
dicated by arrow 508, to a graph drawer, indicated 
by functional block 510. The graph drawer includes 

75 conventional graphing and CRT display control 
software, which causes a graphical representation 
of the electrical signal to be displayed in a window 
512 on CRT display 56 as a waveform 514 on 
graticule 515. 

20 Smalltalk-80 windowing and graphing software 
provides a capability of graphically defining a rec- 
tangular portion of a screen display. Convention- 
ally, this software recalls from computer memory 
the data pertaining to the selected portion of the 

25 displayed waveform and displays such selected 
portion in enlarged format within window 512. The 
accuracy of the enlarged displayed waveform is 
limited, however, to the accuracy and resolution 
with which the electrical signal was acquired and 

30 digitized to provide waveform 514. Signal viewing 
control enables the user to overcome this limitation 
by reacquiring a new electrical signal and 
waveform to be displayed, by adopting rectangle 
516 as specified by the user, as a desired acquis!- 

35 tion window for controlling the digitizer to reacquire 
the electrical signal. 

To do this, signal viewing control includes 
softwave, indicated by functional block 518 for es- 
tablishing the location and size of the desired ac- 

40 quisition window. The window location is transmit* 
ted, as indicated by arrow 520, in the form of 
screen coordinates for the comer points of rectan- 
gle, to a windowing transform function, indicated by 
block 522. This windowing transform function con- 

45 verts rectangle 516 from the screen coordinate 
system to the time/voltage coordinate system of 

• . the signal, producing the acquisition window. This 
new window is output to the digitizer driver 504. 
Upon receiving the acquisition window in 

so time/voltage coordinates, the digitizer driver cal- 
- culates new digitizer settings and transmits these 
via communications path 524 over the CPIB bus to 
the digitizer. 

Such coordinates are also input within the com- 

55 puter to windowing transform 506, as indicated by 
data flow path 526. Similarly, location and dimen- 
sions of display window 512 are input in the form 
of screen coordinates to the windowing transform 
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as indicated by data flow path 528. These data are 
employed, as described hereinafter, in redefining 
the windowing transform of block 506 that is to be 
applied to the next set of digitized electrical signal 
data to be acquired. 

Controlled by these new settings, digitizer 74 
acquires a new electrical signal from the device 
under test, for a signal acquisition window that 
corresponds as closely to desired acquisition win- 
dow 516 as the built-in setting options of the par- 
ticular model of digitizer permit 

The electrical signal is acquired and digitized 
according to the new acquisition window. The 
digitized waveform is input to the workstation, be- 
ing converted to time/voltage coordinates by the 
digitizer driver 504. The new data is processed 
through the windowing transform 506, as modified 
by the screen coordinates and the/voltage coordi- 
nates input via paths 526 and 528 and forwarded to 
graph drawer 510 for display on the screen. The 
new signal, which approximates that portion of 
waveform 514 within rectangle 516 but In greater 
detail, is then displayed in enlarged form within 
display window 512. The succeeding sections of 
this description describe the structure and opera- 
tion of the preferred form of software for imple- 
menting the above-described system in greater de- 
tail. 



5.2 Description of Digitizer Control Software 

FIG. 43 shows a top level state diagram for the 
signal viewing software. This description proceeds 
in the same manner as the foregoing general de- 
scription, commencing with a program START 530, 
which enters the routine at an "acquire data" state 
indicated by block 532. Once initial data is ac- 
quired, control of the program shifts to the "convert 
data to waveform" state, indicated by block 534. 
Blocks 532 and 534 include the functions per- 
formed by the digitizer driver 504. Following con- 
version, the waveform data is input to a "draw 
graph" state 536. In this state, a graphing softwave 
module causes the waveform to be displayed on 
display screen 56. After displaying the waveform, 
program control is transferred to a "wait" state 538. 

In the "wart" state, the computer waits for the 
user to depress one of the three control buttons on 
mouse 60. If the user presses the system button, 
program control switches to the system menu state 
540. From this state, the user can select from 
among several conventional graphing software 
functions: a reframe function 542, a move function 
544, and close function 546. Operation in the sys- 
tem m nu state 540 is conventional and th refore 
need not be further discussed. 

When the user selects the choice button on the 



mouse, this action causes conventional software to 
display a choice menu, as indicated by block 548. 
The choices displayed in th choice menu enable 
the user to select from among several options, to 

5 determine the choice of a signal acquisition window 
to be used by the digitizer 74 in acquiring and 
digitizing a next electrical signal data set 

The first choice is the "zoom in" state, in- 
dicated by block 550, operation of which was dis- 

io cussed above with reference to FIGS. 15-19. The 
second choice is the "zoom out" state, indicated 
by block 552, which enables the user to enlarge 
the signal acquisition window by a predetermined 
amount Other states that the user may select 

T5 include recalling a previous window stored in com- 
puter memory 34 (block 554) and "vertical" and 
"horizontal" states, indicated by blocks 556 and 
558, which enable the user to control the signal 
acquisition window in a single dimension at a time. 

20 similarly, the user can select a trigger level for the 
acquisition window (block 560), select a trigger 
slope (block 562), or perform other acquisition- 
based functions as called for by the particular kind 
of instrument being used. 

25 Ail of these functions return to the "acquire 
data" state 532 upon execution. The "zoom in" 
state includes a "watt" state 551, which operates 
while the user is selecting a window size for rectan- 
gle 516. The rectangle coordinates are finally es- 

30 tablished by the user depressing the third, or point- 
ing, mouse button to indicate the desired acquisi- 
tion rectangle's origin, moving the mouse while 
holding the third button down until the desired 
rectangle has been indicated, and then releasing 

35 the button. This action returns the control to the 
"acquire data" state 532. 

Additional, conventional control functions can 
also be provided on the choice menu, such as 
cursor control (block 564), delta cursors (block 

40 566), save/use data control (block 568), and others 
as will be understood by those skilled in the art 

FIG. 44 illustrates the "acquire data" state 532 
in greater detail. Operation of the signal viewing 
- program commences at START block 530. Upon 

45 startup, the first procedure is to bad default set- 
tings for an initial signal acquisition window of the 
digitizer, as illustrated by block 570. These settings 
are saved by procedure 572, which inputs the 
settings as a first acqRect 574 into a push-down 

so stack 576, operation of which is conventionally con- 
trolled by use of a stack pointer 578. The default 
settings are then input to a "vertical settings" stale, 
which is illustrated in general by block 580 and in 
further detail in FIG. 45a. Once the vertical settings 

55 are established, program control is shifted to a 
"horizontal settings" state as shown generally in 
block 590 and in further detail in FIG. 46a 

Once the vertical and horizontal settings have 
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been established, program control is shifted over to 
a "get data" state 600. In the "get data" state, the 
first step is a "send s ttings" procedure, tn this 
procedure, the vertical and horizontal settings that 
were previously determined are sent to the digitizer 5 
via the digitizer driver, using the appropriate pro- 
tocols for RS-232 and IEEE488 communications. 
These settings are embodied in computer-type 
commands formatted so as to be understood and 
implemented by the programmable digitizer. The to 
digitizer responds by executing the commands and 
acquiring a new electrical test signal from the de- 
vice under test for the signal acquisition window as 
specified in the settings commands. A portion of 
the electrical signal within the acquisition window is 75 
digitized in accordance with the settings and for* 
matted for transmission as a digital data stream 
back to the computer. Next, a "read data" proce- 
dure causes the computer to acquire the digital 
data from the digitizer via the IEEE488 and Rs-232 20 
buses, with the appropriate protocol conversion be- 
ing made by protocol converter 64. 

Referring to FIG. 43, the acquired data is 
passed to a "convert data to waveform " state 534. 
In this state, the raw data from the digitizer, for the 25 
electrical signal acquired within the previously 
specified acquisition window, is transformed into a 
waveform data structure conforming to the require- 
ments of the data formats required by the graphing 
software for displaying graphical data on display 30 
56. Some models of digitizer return their data as an 
array of numbers scaled correctly to represent vol- 
tages, as well as returning information about the 
horizontal scale factor (time between elements), 
location of time 0 (or location in time of an array as 
element), and the horizontal and vertical units of 
measure. For digitizers that behave in this manner, 
the "convert to waveform" procedure is not re- 
quired. 

The next step is the "draw graph" state 536, 40 
detailed in FIG. 43. In this state, the first procedure 
is an optional "draw graticule" procedure. This 
procedure draws a graph graticule 515 (FIG. 42), if 
required, and relabels the dimensions on the axis 
as necessary. The next procedure is "plot data." 45 
This procedure transforms each element of the 
waveform in the waveform data structure created 
by procedure 534 from waveform coordinates to 
screen coordinates. The screen coordinate points 
for the waveform are then displayed according to so 
applications requirements, e.g., along graticule 515, 
within the boundaries of window 512 on display 56. 
An example of this software is included in the 
Tektronix Plot-10TM software, which is comm r- 
cialfy available. 55 

After the new waveform is displayed, program 
control shifts to the "wait" state 538. A discussion 



of operation of the signal viewing software from 
"choice menu" state 548 is presented after a mor 
detailed discussion of operation in the "vertical 
settings" and "horizontal s ttings" states. 



5.3 Vertical and Horizontal Settings 

Referring to FIG. 44, whenever the user speci- 
fies an acquisition rectangle 516 (FIG. 42), the 
computer needs to determine appropriate vertical 
and horizontal component settings to send to the 
digitizer. Any desired acquisition rectangle 
(AcqRect), such as rectangle 516 in FIG. 42, can 
be set to have a vertical component 51 6Y (FIG. 
45b) and a horizontal component 516x(F1G. 46b). 

A test instrument such as a digitizer, is con- 
ventionally designed to provide a set of ordered 
vertical ranges, expressed In volts peak-to-peak 
and commonly called the range setting 602. A 
selected range has a center which is located rela- 
tive to the origin (zero volts) by an amount of offset 
604, conventionally expressed as a percentage, + 
or -, of vertical range. Finally, the test instrument is 
constrained to operate within a range of minimum 
and maximum offsets (minOffset 606 and maxOff- 
set 608). An offset outside of this range would 
cause the range 602 to exceed the upper or lower 
limits of the instrument's operational capability. 

A user of a manually-controllable test instru- 
ment typically manipulates the range and offset 
controls until the display "looks right" This is done 
interactively by changing the range setting to ob- 
tain the proper size of display of the desired signal 
and altering the offset setting whenever a change 
in the range setting causes a portion of the 
waveform to be lost above or below the signal 
viewing area. This kind of interactive control cannot 
conveniently be performed on a programmable test 
instrument because of the need to translate 
changes in settings into computer commands for 
controlling the settings. 

The present invention eliminates this difficulty 
by enabling the user to graphically specify the 
desired acquisition window 516, having a vertical 
component 51 6Y and a horizontal component 
51 6X. By procedures 580 (FIG. 45a) and 590 (FIG. 
46a), the system can automatically determine from 
the desired acquisition rectangle components, the 
vertical and horizontal component settings for the 
test instrument that best fit the desired acquisition 
rectangle. 

Procedure 580, shown in FIG. 45a, automati- 
cally determines the vertical settings for the test 
instrument that best fit the v rtical component 51 6Y 
of the desired acquisition rectangle 516. The first 
step in the "vertical settings state 580" is to select 
from a prestored range table, a range setting, as 
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shown by block 610. The n xt procedure, shown in 
block 612. calculates an offset value-within the 
limits of prestored minOtfset 698 and maxOffset 
608-that most nearly centers the range 602 around 
the acquisition rectangle's vertical component 
51 6Y, without violating the minimum and maximum * 
offset constraints of the instrument The last proce- * 
dure, shown in block 614, determines whether the 
selected range setting and calculated offset setting 
combine to encompass the desired acquisition rec- 
tangle vertical component 51 6Y. If they do not and 
there remain range settings in the table to check, 
control is returned to block 610 and another range 
setting is selected and tested as described above. 

Briefly, this procedure calls for choosing the 
smallest range setting in volts peak-to-peak and 
offset such that: 

minOffset £ offset S maxOffset ; acqRect top S 

range * offset/100 + range/2 ; and 

acqRect bottom 2 range * offset/100 - range/2 . 

If no combination of range and offset are adequate, 
the largest range setting should be used. Addition- 
ally, the user can be notified of this condition. 

An operative example of software implementing 
the "vertical settings" state in Smalltalk-80 lan- 
guage in workstation 50 appears in the program 
listing of APPENDIX H. APPENDIX Q lists the 
definitions of the signal viewing variables used 
above and in APPENDICES H and 1. APPENDIX G 
also includes an example of default settings for the 
digitizer. 

Referring to FIG. 46a, the "horizontal settings- 
state 590 similarly determines and sets the digitizer 
settings for the horizontal component 51 6X of the 
desired acquisition rectangle 516. As shown in FIG. 
46b, four different horizontal digitizer windows can 
be established around the horizontal component 
51 6X of the acquisition rectangle. 

The first choice is a horizontal acquisition win- 
dow 61 6A which completely encompasses the hori- 
zontal component 51 6X by including the sample 
point at or immediately before the earliest (or left) 
edge of the horizontal component and the sample 
point at or immediately after the latest (or right) 
edge of the horizontal component 

The second choice is a window 61 6B that 
encompasses the horizontal component by includ- 
ing the sample point at or immediately after the 
earliest (or left) edge of the horizontal component 
and the sample point at or immediately before the 
latest (or right) edge of the horizontal component 

The third choice is a horizontal acquisition win- 
dow 61 6C that encompasses the horizontal compo- 
nent by including the sample point at or imme- 
diately before the earliest (or left) edge of the 
horizontal component and the sample point at or 



immediately before the latest (or right) edge of the 
horizontal component 

. The fourth choice is a window 61 6D that en- 
compasses the horizontal component by including 

s the sample point at or immediately after the earliest 
(or left) edge of th horizontal component and the 
sample point at or immediately after the latest (or 
right) edge of the horizontal component 

Referring to FIG. 46a, the acquisition window's 

io horizontal component is expressed in terms of a 
number of samples corresponding to the length of 
the acquisition window's horizontal component 
51 6X, and a delay, also expressed as number of 
samples, of the beginning of the acquisition window 

is from the origin (time = 0). In FIG 46b, the tic- 
marks along the horizontal axis indicate time inter- 
vals at which the test instrument takes samples. 
The typical test instrument has a set of available 
sampling rates and both a minimum and a maxi- 

20 mum delay, all of which are provided to the com- 
puter for use in determining the horizontal acquisi- 
tion window settings for the test Instrument 

In FIG. 46a, the first step in "horizontal set- 
tings" state 590 is to select a sampleRate setting, 

25 as shown by block 620, from a prestored table of 
such settings available to the instrument 

The next procedure, shown in block 622, cal- 
culates a delay setting 0.e., within the prestored 
limits of minDelay and maxDelay) to offset the 

so beginning (or left) edge of the horizontal acquisition 
window of the digitiser with respect to the begin- 
ning (or left) edge of the desired horizontal acquisi- 
tion window. This setting can be the sample imme- 
diately preceding or following the beginning of the 

as desired horizontal component. The test used to 
select the exact value of delay depends upon the 
user's choice of horizontal component 61 6 A, 61 6B. 
616C or 616D. 

Procedure 622 also calculates the total number 

40 of samples that would be produced, given the 
delay and sampleRate settings, and limits that 
number to a prestored value specifying the maxi- 
mum number of samples to be taken, maxSam- 
ples. The test used to select the exact value of 

45 delay again depends on the user's choice of hori- 
zontal component 61 6A. 616B, 61 6C, or 61 6D. 

The last procedure, shown by block 624? deter- 
mines whether the selected sampleRate, the se- 
lected delay setting, and the calculated number of 

so samples combine to encompass the desired ac- 
quisition rectangle horizontal component in the 
manner desired (he., window 61 6A, 61 6B, 61 6C, or 
61 6D). ff they do not and there are sampleRate 
settings left to check in the table, control is re- 

55 turned to block 620 and another sampl Rate set- 
ting is s lected and tested, as described above, 
Otherwise, control is transferred back to the block 
532 of the top level state shown in FIG. 43. 

31 
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Briefly summarizing, this "horizontal settings'' 
procedure calls for choosing the highest sample 
rate (he., most samples per second) such that 

minOelay < delay < maxDelay ; 

samples < maxSamples ; 

acqRect left > delay/sampleRate ; and 

acqRect right < delay + samples/sampleRate . 

APPENDIX I is a program listing written in 
SmaIrtalk-80 language for the "horizontal settings" 
state, implementing horizontal acquisition window 
61 6X. APPENDIX G defines the signal viewing vari- 
ables used above and in APPENDIX L 



5.4 Operation in the Menu Choice State 

Referring back to FIG. 43, after an initial signal 
has been acquired and a corresponding waveform 
displayed on the display screen, and the signal 
viewing program is in the "wait* state 538, the user 
can invoke the choice menu (block 548) by de- 
pressing the choice button on mouse 60. 

Referring to FIG. 16a, an initial waveform for 
the AM Modulation Experiment has been acquired 
and displayed on display 56 within window 172. 
The dimensions of the initial acquisition window 
and graticule were set in accordance with the ini- 
tialization or default settings of procedure 570 (FIG. 
44). When the user presses the choice button on 
the mouse, a procedure 548 causes menu 173 to 
be displayed on the screen in the location of the 
mouse cursor. The menu displays a set of com- 
mands available to the user, the topmost one of 
which is initially highlighted. The user can change 
conunands by moving the mouse and thereby the 
highlight down through the list of commands. 

Selecting the first command invokes the "zoom 
in" state, as shown in FIG. 17. The first step in the 
"zoom in" state, is a "rectangle from user" proce- 
dure. This procedure is a standard SmaIItalk-80 
routine that prompts the user to designate a rectan- 
gle on the display screen which encompasses a 
portion of the signal of interest to the user. The 
prompt is in the form of a comer symbol initially 
positioned within window 512 on display 56. The 
user can locate the comer symbol anywhere on the 
display screen to designate, by pushing and hold- 
ing down the mouse's pointer button, an upper left 
hand comer of a desired acquisition window. The 
location of this designated comer wilt be inter- 
preted with respect to the acquisition window of the 
currently-displayed waveform, even If the desig- 
nated comer is not within the boundary of the 
displayed window 172. 

Next, by moving the mouse while holding down 
the pointing button, the user can move the lower 



right com r to form rectangle 174, which is high- 
lighted or shaded on the display. When rectangle 
encompasses the portion of waveform that is of 
interest to the user, the user releases the mous 
s button. The designated area is then stored, in 
terms of screen coordinate system, as a variable 
screenRect 

Program control is then shifted to a procedure 
which compares the extent of variable screenRect 

io with an arbitrary, prestored minimum value 
minimumZoomExtent If the extent of the screen- 
Rect is less than this minimum value, control is 
passed to the "wait for button" state 551 (FIG. 43) 
to enable the user to designate another operation. 

is This mechanism of checking for a very small rec- 
tangle prevents activity when the pointing button is 
inadvertently pressed and immediately released, 
and when the user wishes to cancel a "zoom-in" 
operation. 

20 Operation of the "acquire data" state, as pre- 
viously described, causes a new electrical signal to 
be acquired by the digitizer from the device under 
test and a new waveform to be displayed on dis- 
play 56, as shown in FIG. 17a, in a modified 

25 graticule that displays the new coordinates for ac- 
quisition rectangle 174. Because the signal is reac- 
quired by the digitizer, the waveform displays the 
signal features in substantially greater detail than 
the corresponding signal features for the waveform 

30 in FIG. 16a 

Routines 538 and 548 (FIG. 43) can be ac- 
tuated by the user to again invoke the choice menu 
173, this time selecting the "zoom out" state. In 
this state, the. acquisition rectangle used in the 

35 prior operation is expanded by a prestored expan- 
sion factor expressed as a percentage of the hori- 
zontal and vertical components. After the zoom out 
settings have been determined and transmitted to 
the digitizer and by the computer, the digitizer 

40 obtains a third electrical signal from the device 
under test and returns the digitized version of such 
signal to the computer. The computer then displays 
the signal, as a waveform having a coordinate 
system that is modified to reflect the enlarged, 

45 zoom out acquisition window. 

Again invoking menu 173, the user can des- 
ignate and recall the "previous window," Le., cor- 
responding to the window of FIG. 16a. This proce- 
dure sets the acquisition rectangle, acqRect, equal 

so to the last one stored in the stack 576, as shown in 
FIG. 44. A new waveform is then acquired from the 
device under test by the digitizer for the previous 
window. Essentially the same signal features are 
displayed but the waveforms are not necessarily 

55 identical. They can vary in both magnitude and 
shape and in delay position along the horizontal 
axis. This is because th new waveform is not 
merely a replay of data previously stored for the 
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prior vaveform but is a waveform for a signal newly 
acquired by the digitizer within the same acquisi- 
tion window. This feature of th invention enabl s 
multiple tests of the sam signal features to b run 
repeat dly, .g., for comparative analysis. 

The choice menu (state 548) can also be in- 
voked to select the "horiz" procedure. The "horiz" 
procedure causes the test system to obtain a test 
signal within a signal acquisition window which has 
the same vertical component as the prior window, 
but has a horizontal component that is greatly 
extended in both the negative and positive direc- 
tions relative to the signal feature shown. Selection 
of the "vert" command in menu 173 performs 
essentially the same expansion as "horiz" but in 
the vertical dimension. 

From the foregoing description, it should be 
apparent to those skilled in the art that other prog- 
rammable, two-dimensional signal acquisition in- 
struments, such as a spectrum analyzer, can be 
similarly controlled. The same principles can also 
be applied to the control of programmable 
stimulus-type instruments, as summarized below. 



5.5 Stimulus Instrument Control 

Stimulus-producing test instruments (those pro- 
ducing electrical, mechanical, acoustical, etc. sig- 
nals) often have more than one setting required to 
define their operation. When a combination of set- 
tings dimensions can be presented as a multi- 
dimensional graph, the settings thus represented 
may be adjusted simultaneously. 

This multi-dimensional control is achieved by 
representing the values of the various settings as a 
single point in the multi-dimensional space. Control 
over the various settings is achieved by adjusting 
the position of a representation of that point in the 
space. An example of such control is presented in 
the following Power Supply Control description, 
FIGS. 47 and 48, and APPENDIX J. 

Another form of graphical control involves pre- 
sentation of some prototypical signal with 
"adjustment points" graphically depicted. Each ad- 
justment point controls a single parameter of the 
stimulus signal with immediate graphical feedback 
of the overall effect FIG. 49 shows application of 
such method of control to a programmable 
waveform generator. 



5.5.1 Power Supply Control 

FIG. 47 demonstrates control over a power 
supply as an example f a stimulus-producing test 
instrum nt. Power supplies are typically controlled 
in terms of maximum voltage and current limits. 



These limits must be set by the user within the 
operating region for the particular power supply 
being used, information about the operating region 
is typically provided to the user in the form of 

5 numbers defining upper and lower current and volt- 
age capabilities of the power supply. The user 
must then keep these numbers in mind, or look 
them up, when setting the current and voltage 
limits of the instrument for an experiment 

io In this example of the invention, these features 
are displayed for the positive power supply section 
of a Tektronix PS5010 power .supply in a two- 
dimensional graph 700 representing current in the 
x dimension and voltage in the y dimension. The 

rs graph's dimensions are established to contain the 
power supply's operating region. (An additional 5% 
expansion is depicted for viewing convenience but 
is not necessary.) The darkened gray area 702 
represents the actual operating region of the power 

20 supply. The shape of the operating region happens 
to be L-shaped for this particular power supply but 
need not be. Other models of power supply com- 
monly have a triangularly shaped operating region. 
The power supply's combined operating point 

25 704, composed of the voltage setting and current 
setting operating points (i.e., positions on their re- 
spective axes), is constrained to be within this 
region. A horizontal line 706 extends from the com- 
bined operating point toward the graph's voltage 

30 axis (where current is zero) to the y-axis graticule 
708. A vertical line 710 extends from the combined 
operating point toward the graph's x axis (where 
voltage is zero) to the x-axis graticule 712. These 
lines serve to delineate the level or operating point 

35 of each power supply setting. 

Settings are often combined mathematically to 
produce a value of additional interest By providing 
a two-dimensional representation, not only can the 
individual dimensions be represented, but their 

40 combined effect can also be shown. In this exam- 
ple, the power (in watts) provided by the instrument 
is the product of the voltage and current settings, 
and is shown by the intersection of the two lines at 
the combined operating point 

45 A digital readout 714 of voltage, current, and 
power is provided in the upper right comer of the 
graph to facilitate precise control. The placement of 
this readout is arbitrary. For example, the voltage 
readout may be displayed attached to the voltage 

so line in some way, e.g., to the left in the graticule 
area. The current readout may be displayed at- 
tached to the current line, e.g., centered and to the 
right The power readout might be attached to the 
intersection of the operating point lines. 

55 User control is implemented by power supply 
control software diagrammed in FIG. 48 and listed 
in part in APPENDIX J. When this routine is in- 
voked (START block 718), the first procedure is 
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"draw graph" 720, as explained above. Shifting to 
a "wait" state 722, the user controls the power 
supply by moving a cursor (by activating a mouse, 
joystick, or other two-dimensional graphic input de- 
vice) within the constraint region 702. Depressing 5 
the selector or position button adjusts the operating 
point (block 724) in a manner depending on the 
position of the cursor, in a preferred implementa- 
tion, the cursor will then jump to: 

1) the center point of the voltage line 706 w 
(block 726), 

2) the combined operating point 704 (block 
728), or 

3) the center point of the current line 710 
(block 730), 75 

depending upon which was closest when the 
selector button was depressed. In a variation of this 
interface, small targets might be attached to the 
lines' mid-points and to the combined operating 
point. The user would select the desired type of 20 
interaction by moving the cursor near the appro- 
priate target before depressing the selector button. 

Once the cursor is attached to one of these 
points, .moving the cursor will change: 

a) the position of the voltage operating point, 2s 
if 1) above, without modifying the current setting 

b) the position of the combined voltage and 
current operating point if 2) above, 

c) the position of the current operating point, 

if 3) above, without modifying the voltage setting. so 
APPENDIX J lists the method for selecting among 
points 704, 706 and 710, and the method of adjust- 
ment upon selecting the combined operating point 
704. 

In a simplified implementation, the cursor can 35 
be made to always jump immediately to the com- 
bined operating point, thus denying independent 
setting of voltage or current operating points. 

Once the desired settings are established, they 
are converted to power supply control commands 40 
by routine 732. Three ways of dealing with the 
resulting power supply settings are reasonable: 

1) sending the voltage and current operating 
points to the power supply as a user slides the 
lines within the display, 45 

2) sending the operating points only after the 
user has positioned the new combined operating 
point, or 

3) holding the operating points for later set- 
ting by some other part of a larger instrument so 
system. 

As used in the BLOCK DIAGRAM EDITOR 
SYSTEM, the third alternative is preferred for mak- 
ing initial settings, followed by use of the second 
alternative to enable interactive control during ex- 55 
ecutlon of an experiment 

A choice menu (block 734) may also be imple- 
mented to facilitate op ration of the pow r supply. 



As shown in FIG. 48, choices can include "zooming 
in" on a user-designated subsection of the operat- 
ing region to provide finer placement of the operat- 
ing points and, thus, finer control. A "zoom out" 
function can be provided to undo the effects of a 
"zoom in" function. A "previous setting" choice 
can restore the previous combined operating point 
fpom a stack of operating points saved as settings 
were adjusted. A "power on" and a "power off" 
choice may be provided for turning the supply's 
output switch on and off. Further choice menu 
items may be implemented for directly setting op- 
erating points for specific applications (e.g., for 
logic families: "TTL" (5V, maximum current); 
"ECL" (-5.2V, maximum current)). 



5.5.2 Signal Generator Control 

Another form of graphical control involves pre- 
sentation of some prototypical signal with "setting 
points" graphically depicted. Each adjustment point 
controls a single operating point of the stimulus 
signal in two dimensions with immediate graphical 
feedback of the overall effect This form of control 
is to be distinguished from systems, the Macintosh 
music systems, for example, which use "sliders" to 
establish setting values (one dimension each) by 
positioning each slider along a graticule and adopt- 
ing the position of each as one parameter of a 
waveform to be generated. The waveform, how- 
ever, is not displayed and graphically manipulated 
by movement of the sliders in such systems. This 
form of graphical control also differs from a known 
cursor tracking system for "drawing" a waveform to 
be "played" by the system. The latter system 
converts screen points of a waveform drawn by the 
user into amplitude samples and passes the sam- 
ples through a digital-to-analog converter to pro- 
duce an analog signal closely approximating the 
user-drawn waveform. 

FIG. 49 shows a user interface to a signal 
generator (such as the Tektronix FG5010). A two- 
dimensional graph 750 displays a waveform 752. A 
pop-up-menu 754 is used to specify which 
waveform type (sine, square; or triangle) is to be 
generated. This selection is "digital" in nature: only 
one of a set of choices is available, with no inter- 
mediate forms. In the displayed example, the 
"triangle" waveform has been chosen. A graphical 
representation of the waveform is displayed with 
rectangular targets over points representative of the 
waveform's operating points: target 756 for peak-to- 
peak amplitude; target 758 for dc offset; target 760 
for percent waveform symmetry; and target 762 for 
period. In this example, the operating points are 
adjusted by moving a cursor into (or near) a par- 
ticular target, depressing a selection button on the 
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mouse to select the nearest target and, while the 
button is depressed, moving the mouse to move 
the selected target. As the target is moved, the 
displayed representation of the signal generator's 
output waveform is adjusted to illustrate the 
change. The actual operating point values may be 
displayed in a read-out window 764. As in the 
power supply example, the operating points are 
constrained by the design of the instrument. In this 
example, adjustment simply stops when these lim- 
its are reached (i.e., continued movement of the 
mouse produces no effect). 

When an operating point such as frequency, 
may be adjusted over several orders of magnitude 
(e.g., 0.002 Hz to 20 MHz in the FG5010), two 
different techniques are used to illustrate the effect 
on the displayed waveform. Small or slow move- 
ments cause the signal representation to change, 
allowing the operating point to be established with 
great precision. When large or fast movements of 
the positioning device are detected, the peviod 
graticule 766 adjusts, rather than the signal repre- 
sentation. By pushing the operating point target, 
the user causes the graticule to adjust achieving 
the same effect the representation of the output 
waveform is properly displayed with respect to the 
graph. 

Having illustrated and described the principles 
of our invention in a preferred embodiment with an 
operative example thereof, it will be appreciated by 
those skilled in the art that the invention may be 
modified in arrangement and detail without depart- 
ing from such principles. We claim all modifications 
coming within the spirit and scope of the following 
claims. 



Claims 

1 . A graphical user interface system for a user 
interactively to edit and program a block diagram 
for execution by a computer, the system compris- 
ing: 

a programmable computer including memory 
means for storing computer program instructions 
and data and processing means for executing the 
stored program instructions to manipulate the 
stored data; 

a graphical display means connected to the 
computer for displaying two-dimensional graphic 
data; 

input means connected to the computer for input- 
ting data to the computer, including user-operable 
means for selecting and positioning graphic data 
displayed on the display m ans; 

block display means responsive to the user- 
operable means for displaying a plurality of user- 
selected blocks as graphical data on the graphical 



display means, said blocks including a first block 
having an output terminal and a second block hav- 
ing an input terminal; 

interconnection display means responsive to 

s the user-operable means for displaying an intercon- 
nection between the output terminal of the first 
block and the input terminal of the second block; 

first prestored function instruction means 
associated with the first block and executable by 

w the processing means for generating a first set of 
signal data in accordance with a predefined first 
function and providing the signal data at the output 
terminal of the first block; 

data flow means associated with the displayed 

75 interconnection for transmitting signal data between 
functions in a direction determined by the intercon- 
nection from the output terminal of the first block to 
the input terminal of the second block; 

second prestored function instruction means 

20 associated with the second block and executable 
by the processing means for transforming the input 
signal data in accordance with a predefined second 
function; 

means responsive to the input means for 
25 actuating the processing means to execute the first 
and second function instruction means to generate 
said first set of signal data in accordance with the 
first function,- to transmit the signal data via the 
data flow means to the second function, and to 
30 transform the signal data in accordance with the 
second function to produce a second set of signal 
data; and 

means for actuating the graphical display 
means to display the second set of signal data. 

35 2. A system according to claim 1 including: 

block storage means for storing a plurality of 
unique function instruction means, each in associ- 
ation with a predetermined user-selectable block, 
including said first and second function instruction 

40 means stored in association with the first and sec- 
ond blocks, respectively; 

means, responsive to operation of the user- 
operable means and block display means to select 
and display each user-selected block, for selecting 

45 the function instruction means associated with each 
user-selected block; 

means, responsive to operation of the user- 
operable means to display an interconnection be- 
tween the output terminal of the first user-selected 

so block and the input terminal of the second user- 
selected block, for assembling the function instruc- 
tion means for each user-selected block for execu- 
tion by the processing means in a sequence deter- 
mined by the direction of signal data transmission 

55 by th data flow means. 

3. A system according to claim 2 in which each 
block and associated function instruction means in 
the block storage means has a unique identifier, 
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th system including: 

means for displaying a list of block names 
corresponding to the identifiers on th graphic dis- 
play means; and 

means responsive to operation of the user- 
operable means to select and position one of said 
names on the display, means to display the name 
as a block; 

the means for selecting and assembling the 
function instruction means being operable to ad- 
dress the unique identifiers. 

4. A system according to claim 2 in which the 
selecting and assembling means includes: 

means for storing block diagram configuration 
data for the displayed diagram, including the 
names of the displayed blocks and their intercon- 
nections; 

means for assembling a netlist of the 
displayed blocks and interconnections; and 

means for controlling assembly and execution 
of the function instruction means for the displayed 
blocks in accordance with the netlist: 

5. A system according to claim 2 including 
means, responsive to the user operating the user- 
operable means to select and display at least two 
of said first blocks and interconnections therefrom 
to the second block, for executing the selected 
function instruction means for each first block and 
for outputting resultant sets of said signal data from 
each first block to the second block in substantially 
parallel operation. 

6. A system according to claim 2 including 
means, responsive to the user operating the user-* 
operable means to select and display at least two 
of said second blocks and interconnections thereto 
from the first block, for executing the selected 
function instruction means for each second block 
on the signal data transmitted by the data flow 
means for each interconnection. 

7. A system according to claim 2 in which the 
block storage means includes a third function in- 
struction means stored in association with a third 
block having an input terminal and an output termi- 
nal and executable by the processing means for 
transforming an input set of signal data in accor- 
dance with a third predetermined function and out- 
putting the transformed set of signal data at Its 
output terminal. 

8. A system according to claim 1 in which at 
leaxt one of the function instruction means includes 
a user-settable parameter responsive to user op- 
eration of the input means to set the function 
thereof. 

9. A system according to claim 8 including 
interactive means operable during execution of a 
block diagrar, for displaying, on the graphical dis- 
play means, a notification to the user which func- 
tion instruction means is about to b executed. 



10. A system according to claim 9 in which the 
interactiv means includes means for interrupting 
execution until the user actuates the input means. 

11. A system according to claim 8 including 
5 means for interrupting execution when said on 

function instruction means is about to be executed 
and means responsive to actuation of the input 
means for setting said parameter. 

12. A system according to claim 11 in which 
w the parameter includes a two-dimensional output 

function and the means for setting said parameter 
includes means for displaying a representation of 
said function on the graphical display means, 
means responsive to operation of the user-operable 
is means for graphically modifying said representa- 
tion, and means for converting the modified repre- 
sentation into a modified setting of the two-dimen- 
sional output function. 

13. A system according to claim 1 including 
20 means for selectively removing interconnections 

between the blocks and means for disassembling 
the data flow means associated with the removed 
interconnection. 

14. A method of computer-controlling a phys- 
25 leal system, comprising: 

providing computer-controllable means for 
stimulating the physical system; 

providing computer-controllable means for 
detecting a response to stimulation of the physical 
30 system; 

providing a computer including user input 
means for a user to enter instructions, user display 
means for graphically displaying information to the 
user, and external communications means for 
35 sending and receiving data; 

connecting the computer communications 
means for sending control signals via a first data 
channel to control the stimulating and detecting 
means and for receiving, via a second data channel 
40 from the detecting means, a data signal that de- 
fines a response of the physical system to the 
stimulation; 

programming the computer to display a block 
diagram including a first block defining the stimu- 

45 lating means and a second block defining the de- 
tecting means; 

storing in association with the first block a 
variable stimulation parameter genericaily defining 
a form of stimulation that the stimulating means is 

so capable of providing to the physical system; 

storing in association with the second block a 
variable detection parameter genericaily defining a 
feature of the response that the detecting means is 
capable of detecting; 

55 programming the computer to generat and 

send control signals to the stimulating and detect- 
ing means to actuate stimulation of the physical 
system and detection of the respons thereof in 
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accordance with the stimulation and detection pa- 
rameters; 

entering in association with a selected one of 
the first and second blocks an instruction setting 
the variable parameter thereof to a specific stimula- 
tion or detection parameter; 

executing the program to cause the computer 
means to send said control signals to the stimulat- 
ing and detecting means to cause each in turn to 
stimulate the physical system and detect the re- 
sponse thereof in accordance with the specific 
stimulation parameter; 

transmitting to the computer a data signal 
corresponding to the detected response of the 
physical system; and 

processing the data signal and displaying in 
association with the second block a representation 
of the detected response, the displayed represen- 
tation of the response being determined by said 
stimulation and detection parameters. 

15. A method according to claim 14 in which 
the detecting means is operable to detect the re- 
sponse of the physical system in two dimensions 
defining a signal acquisition window, including stor- 
ing two of said variable detection parameters cor- 
responding to the two dimensions, entering in as- 
sociation with the second block an instruction set- 
ting at least one of the two variable parameters to 
specific detection parameters to determine said 
acquisition window, operating the detecting means 
to acquire signal data defining said response in 
accordance with the signal acquisition window de- 
termined by the two specific parameters, and dis- 
playing a two-dimensional representation of the ac- 
quired signal data within a display window defined 
by said two parameters. 

16. A method according to claim 15 including 
superimposing a modified display window over a 
portion of the signal represented in the display 
window, converting the modified display window 
into modified detection parameters, and operating 
the detecting means in accordance with the modi- 
fied detection parameters to acquire a second re- 
sponse within a modified signal acquisition window 
determined by the modified detection parameters. 

17. A method according to claim 14 in which 
the stimulating means is operable to generate a 
test signal having signal features in two dimen- 
sions, including storing two of said variable stimula- 
tion parameters corresponding to the two-dimen- 
sional signal features, entering in association with 
the first block an instruction setting the two variable 
parameters to specific stimulation parameters, and 
operating the stimulating means to generate the 
two-dim nsional test signal in accordance with th 
two specific parameters. 



18. A method according to claim 17 including 
displaying a two-dimensional representation of the 
variable stimulation parameters, displaying and po- 
sitioning a point on said two-dimensional repre- 

5 sentation, and converting coordinates of said point 
to said two specific parameters. 

19. A method according to claim 14 in which 
said computer is further programmed to display: 

a third block defining the physical system; 
70 a first signal path connecting an output of the 

first block to an input of the third block; and 

a second signal path connecting an output of 
the third block to an input of the second block. - 

20. A method according to claim 19 including 
T5 storing information about the physical system, said 

information normally being suppressed but being 
displayable upon request of the user by actuation 
of the input means. 

21. A method according to claim 19 including 
20 storing a third block function in association with the 

third block comprising a simulation of the physical 
system, inputting to the third block function data 
corresponding to the stimulation signal, and detect- 
ing the response of the simulation in accordance 
25 with the stimulation and detection parameters. 

22. A method according to claim 14 including 
programming the computer to display a fourth 
block and an third signal path connecting an output 
of the second block to an input of the fourth block, 

30 storing in association with the fourth block a pro- 
cessing function for transforming input signal data, 
and processing the signal data transmitted from the 
detecting means in accordance with the processing 
function. 

35 23. A method according to claim 14 including: 
programming the computer to display a fourth 

block and a third signal path connecting an output 

of one of the first and second blocks to an input of 

the fourth block; 
40 storing in association with the fourth block a 

processing function for transforming input signal 

data; and 

programming the computer to output signal 
data from the connected one of the first and sec- 
45 ond blocks to be input to the fourth block and 
process the signal data in accordance with the 
associated processing function. 

24. A graphical user interface system for a user 
interactively to edit and program a block diagram 
so for execution by a computer, the system compris- 
ing: 

a programmable computer including memory 
means for storing computer program instructions 
and data and processing means for executing the 
55 stored program instructions to manipulate the 
stored data; 

a graphical display means connected to the 
computer for displaying two-dimensional graphic 
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data; 

input means connected to the computer for 
inputting data to the computer, including user-op- 
erable means for selecting and positioning graphic 
data displayed on the display means; 5 

block display means responsive to the user- 
operable means for displaying a plurality of user- 
selected blocks as graphical data on the graphical 
display means, said blocks including a first block 
having an output terminal, a second block having 10 
an input terminal and a third block having an input 
and an output terminal; 

block storage means for storing a plurality of 
unique function instruction means, each in associ- 
ation with a predetermined user-selectable block; 75 

first prestored function instruction means 
associated with the first block and executable by 
the processing means for generating a first set of 
signal data in accordance with a predefined first 
function and providing the signal data at the output 20 
terminal of the first block; 

second and third prestored function instruction 
means associated with the second and third blocks, 
respectively, and executable by the processing 
means for transforming input signal data in accor- 25 
dance with a predefined second and third func- 
tions, respectively; 

interconnection display means responsive to 
the user-operable means for selectively displaying 
interconnections between output terminals of the 30 
first and second blocks and the input terminals of 
the second and third blocks; 

block diagram configuration storage means for 
storing user-selected blocks, interconnections and 
a user-specified configuration thereof and display- as 
ing same as a block diagram; 

means for defining data flow paths associated 
with the displayed interconnections for transmitting 
signal data between functions in a direction deter- 
mined by the interconnections from the output ter- 40 
minals and the input terminals of the blocks; 

means for selecting for execution the function 
instruction means associated with each user-se- 
lected block displayed in the block diagram; 

means for assembling the selected function 45 
instruction means and data flow paths for execution 
by the processing means in a sequence deter- 
mined by the stored block diagram configuration; 

means responsive to the input means for 
actuating the processing means to execute the so 
selected function instruction means to generate 
said first set of signal data In accordance with the 
first function, to transmit the signal data via the 
data flow paths to the second and third functions 
as determined by the block diagram configuration, 55 
and to transform the signal data in accordance with 
the second and third functions to produce a second 
set of signal data. 



25. A system according to claim 24 in which at 
least on of the functi n instructi n m ans includes 
a user-settable parameter responsive to us r op- 
eration of the input m ans to set the function 
thereof. 

26. A system according to claim 25 including 
means for interrupting execution when said one 
function instruction means is about to be executed 
and means responsive to actuation of the input 
means for setting said parameter. 

27. A system according to claim 26 in which 
the parameter includes a two-dimensional output 
function and the means for setting said parameter 
includes means for displaying a representation of 
said function on the graphical display means, 
means responsive to operation of the user-operable 
means for graphically modifying said representa- 
tion, and means for converting the modified repre- 
sentation into a modified setting of the two-dimen- 
sional output function. 

28. A system according to claim 24 including 
interactive means operable during execution of a 
block diagram for displaying, on the graphical dis- 
play means, a notification to the user which func- 
tion instruction means is about to be executed. 

29. A system according to claim 28 in which 
the interactive means includes means for interrupt- 
ing execution until the user actuates the input 
means. 

30. A system according to claim 22 including 
means responsive to the user-operable means for 
grouping a user-selected subset of the displayed 
blocks and associated interconnections into a unit 
and displaying same as a macroblock. 

31. A system according to claim 30 including 
means for storing the macroblock in, and recalling 
it from, the block storage means. 

32. A system according to claim 31 including 
means responsive to the input means for entering 
into a displayed macroblock and displaying the 
internal configuration thereof for the user to view. 

33. A system according to claim 31 including; 
means for displaying a list of identifiers of the 

stored blocks on a first portion of the display 
means; 

means for adding an identifier for the 
macroblock to the list; and 

means responsive to operation of the user- 
operable means for moving a selected identifier 
into a second portion of the display means to be 
displayed as a block and for moving a selected 
block Into the first portion to delete the selected 
block from the second portion. 

34. A syst m according to claim 24 including 
means for actuating the graphical display means to 
display one of the sets of signal data. 
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35. A system according to claim 24 including: 

means for deleting a selected block from the 
displayed block diagram; 

means responsive to deletion of the selected 
block for deleting the displayed interconnections t 5 
and from th selected block; and 

means responsive to deletion of the selected 
block for deleting the selected block and asso- 
ciated interconnections from the block diagram 
configuration data storage means. io 
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* * » 

APPENDIX A Program Listing for I/O Driver Module: fgSOlOA 

/* FG5010A.C 10 driver compatible version of the fg5010A driver. 
02-16-1986 version, */ 

GLOBAL INFORMATION FOR function generatorO . 

- 7 

#include <stdio.h> 
#include <math.h> 
#include "type.h" 
#include tt spd.h" 
#include "sp.h" 

extern FILE * IOChannel; /* Pointer to /dev/comm file */ 

typedef struct { 

int entryCount; 
} STATE, *STATEPTR; 

These are additional function generator settings that may be changed by the 
user 

typedef struct { 

char waveshape[10]; /* 'SINE", "SQUARE", "TRIANGLE" */ 

double amplitude; 

double frequency; 

double offset; 

double symmetry; 

char name[80]; 

} P ARAMS, *PARAMSPTR; /* PARAMS names the data type, 'PARAMSPTR names 
pointers to structure of type PARAMS */ 

/• 

DATA GLOBAL TO foactioa generator 

7 

static char IOmessage[200]; 

/• v 

DRIVER FOR DIGITIZER^ 

7 



star_Afg5010(info) 
CHAINPTR INFO: 



{ 

int AfgSOlOO; 
PARAMSPTR param; 
POINTER para__allocateO; 
char *strcpyO; 

param = (PARAMSPTR) para_allocate (sizeof(PARAMS)); 
sticpy (param ->name, info->blocknam ); 



fscanf(inf ->inputfile, 

"%s %lf %lf %lf %lf fl , 
param - waveshape, 
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&(param->amplitude) > 
&(param ->f requency), 
&(param->offset), 
&(param -symmetry)); 

sendASettings(param); /send new settings*/ 

info->no_output = 1; 
info->no__input = 0; 

star_setup (info,Afg5010,(char *)param, size of (PARAMS)); 

return (0); 
} 



FG5010Q: Star routine for GB5010 function generator. 



* ■» » • 

* v * * * J 



Afg5010(param, size, state) 

PARAMSPTR param; 
int size; 
STATEPTR state; 



{ 



char *alloc_state_var(); 
ERRORTYPE samp__alioc(); 
SAMPLE cur__sample; 
ERRORTYPE errorcode; 

int length_output_fifo()» maxlength_input_fifoO, length_input_fifo(); 
int retCode = 0; 

if (state = NULL) { /• First call */ 

state = (STATEPTR) alloc_state_var(l > sizeof(STATE)); 
if(size ! = sizeof(PARAMS)) return (1); 
if(no_output_fifosO * - 1) return (2); 
if(no_input_fifos() ! = 0) return (3); 
state->entryCount = 1; 
} 

switch (state->entryCount) { 
case 1: 

invertBlock(param ->name); 

sprintf(IOmessage, B FG5010A,OUT ON"); 
if (IODriver (IOmessage) I = NOERROR) 

{printf("IO driver error\n°);} 
if(samp_alloc(&cur_sample) ! = NOERROR) 

printf( ll samp_alloc was unable to allocate 

SAMPLE spaceXn" 
cur_sample->type = INTJSAMPLE; 
cur_sample->uvaLival = 1; 



retCod = put(0, &cur_sample); 
if (retC d = 1) retCod = 0; 
break; 
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case 2: 

sprintf(IOmessage, "FGS010A.OUT OFF"); 
if (IODriver(IOmessage) ! = NOERROR) 

(printfCIO driver error\n B );} 
retCode = 0; 
break; 

default: 

break; 

state ->entryCount++ 
return(retCode); 

} 

sendASettings(param) 

AMSPTR param; 

{ 

/* SEND SETTINGS •/ 

sprintf(IOmessage, "FG5010A:OUT OFF;"); 
if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n*);} 
sprintf(IOmessage, "FGSOlOA^s; - , param ->waveshape); 
if (IODriver(IOmessage) ! - NOERROR) 

{printfCIO driver errorXn 0 );} 
sprintf(IOmessage, "FG5010AAMPL %53f; n , param -amplitude); 
if (IODriver(IOmessage) ! = NOERROR) 

{printf( B IO driver error\n");} 
sprintf(IOmessage, TG5010A,-OFFS %4.3f;% param ->off set); 
if (IODriver(IOmessage) ! - NOERROR) 

{printfCIO driver erroAn 11 );} 
sprintf(IOmessage, "FGSOIOA^REQ %e; B , param->freqnency); 
if (IODriver (IOmessage) ! = NOERROR) 

{printfCIO driver error\n");} 
sprintf (IOmessage, "FG5010A5YM %2.0F, param -symmetry); 
if (IODriver(IOmessage) ! - NOERROR) 

{printf( B IO driver error\n");} 

return; 
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APPENDIX B Program Listing for I/O Driver Module: A7d20 

/* A7d20.c 10 driver compatible version of the A7d20 driver. 
02-25-1986 ♦/ 

GLOBAL INFORMATION FOR A7d20() 

7 

#include <stdio.h> 
#include <math.h> 
#include a type,h B 
#include "spAn" 
#include "sp.h" 
#inciude "digStructures.h 11 

extern FILE *IOChannel; /* Pointer to /dev/comm file */ 

#define OVERDRIVEF ACTOR 200.0 /♦ max divs a sig peaktopeak can cover */ 

typedef struct { 

int dummy; 
} STATE, *STATEPTR; 

/*These are additional digitizer settings that may be changed by the user*/ 

typedef struct { 

int channel; /* 1 or 2 */ 

float trigLevel; /* in divisions */ 

char trigSlope[8]; /• "PLUS" OR tt MINUS B */ 

} SETTINGS; 

typedef struct { 

RECTANGLE AcqRect; 
SETTINGS Settings; 
float maxSignal; 
float minSignal; 

char useWfFlag[4]; /* NO — Don*t send waveform to next star 

YES = send waveform to next star */ 
char title[NAMELENGTHJ; 

} PARAMS, * PARAMSPTR; /* PARAMS names the data type, *PARAMSPTR names 
pointers to structures of type PARAMS */ 

/• - - 

DATA GLOBAL TO digitizer 

V 

extern FILE *responseFile; 

static char RawData[1030]; /* remember to mask: (RawData[i] & 

0377)*/ 

static char IOmessage [200]; 
static int RawSize; 

static WINDOWTRANSFORM RawToWftransf rm; 

static doubl Volts; 
static double P sition; 
static doubl HorizTime; 
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static doubl TrigPos; 
static double Probe; 
static double xZero; 



/* index of trigger point in RawData */ 



DRIVER FOR DIGmZERQ. 



V 



star_A7d20 
CHAINPTR info; 
{ 

int A7d200; 
PARAMSPTR params; 
POINTER para_allocateO; 
char *strcpyO; 
float tempChannel; 

params = (PARAMSPTR) para_allocate (sizeof(PARAMS)); 

f scanf (inf o ->inputf ile, 

"%f %f %f %f %f %s %f %f %f %s% 

&(params->AcqRect.origin.x), 

&(params->AcqRect.origin.y), 

&(params ->AcqRect~extent.x), 

&(params->AcqRectextenty), 

&(params->Settings.trigLevel), 

params ->Settings.trigSlope, 

&tempChannel, 

&(params ->maxSignal) , 

&(params ->minSignal), 

params ->useWfFlag); 

params ->Settings, channel = (int) tempChannel; 
strep y(params->title, info->blockname); 

Probe = 1.0; 
info->no_output = 1; 
info->no_input = 1; 

star_setup (info, A7d20,(char *)params, sizeof (PARAMS)); 



return (0); 

} 



A7d20Q: Star routine for 7D20 digitizer. 



7 



A7d20 (param, size, pState) 



PARAMSPTR 
int 

STATEPTR 



size; 



pState; 



param; 



{ 



char *alloc_state__var(); 
ERRORTYPE samp_allocO; 
SAMPLE cur_sample,x; 
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WAVEFORM *wave; 
INDEX wdim[3]; 

ERRORTYPE errorcode = NOERROR; 

ERRORTYPE create_wf(); 

int length_input_fifo(), maxlength_input_fifo(); 

int tupletype[4]; 

int start, stop; 

FILE *fopen(); 

if(pState = NULL) { /• First call*/ 

pState = (STATEPTR) alloc_state_var(l, sizeof(STATE)); 
if(size ! = sizeof(P ARAMS)) return(l); 
if(no__output_fifosO ! - 1) return(2); 
if(no_input_f ifosO ! 1) return(3); 
} 

if (get (O, &x) = 0) { 

inyertBlock(param ->title); 

if ((x->type ! - INT_SAMPLE) | (x->uvaUval I = 1)) 
printf ("invalid sample sent to A7d20\n°); 

Probe « 1.0; 

newVertSettings(param); /* Calculate and send 

* new vertical settings 

v 

newHorizSettings(parani); 

acquireRawDataO; /* Get raw waveform data */ 

sprintf(IOmessage, 

■A7d20:CH%ld COUP:GND B , 

param ->Settings. channel); 
if (IODriver(IOmessage) ! = NOERROR) 

{printf^IO driver errorXn");} 

/* Find first and last points in RawData 

7 

waveformLimits(param, &start, &stop); 
/* Allocate space for BLOSIM waveform 

v 

wdim[0] = stop - start + 1; 
tupletype[0] = W_FLOAT; 

if ((errorcode = create__wf(l, wdim, l,tupletype, &wave)) 
! = NORERROR) 
printf("CTeate_wf ;reports ERRORCODE %2d \n% 
errorcode); 

/* Make BLOSIM waveform 

7 

makeWaveform(wave, start, stop, param); /* Make BLOSIM 
waveform */ 

/* Send data to Smalltalk 

v 

dataToSmalltalk(param, wave); 



EP 0 295 760 A2 



/* Send waveform to next BLOSIM star if useWfFlag is set 
7 

if (strcmp(param->useWfFlag, "NO")) { 
/* allocate space for cur_sample 

v 

if(samp_aUoc(&cur_sample) ! = NOERROR) 
printfCsamp_alloc unable to allocate SAMPLE 
spaceXn*); 

/* place pointer to wavefor in sample 

7 

cur_sample->type = WAVEJSAMPLE; 
cur__sample->uvaLwave = wave; 

/* output the sample 

v 

if ((errorcode = put (0, &cur_sample)) = 1) errorcode=0; 
rerurn(errorcode); 

} 



static acquireRawDataQ 

{ 

int rawDataSize = 0; 

int i» strcmpO; 

char hold[16]; 

char *strcpy0; 

char header[32], fcighByte, lowByte; 

/* tell 7D20 to get and hold the next waveform 

7 

sprintf(IOmessage, "A7d20:TR HOLDNEXT: ON"); 
if (IODriver(IOmessage) » = NOERROR) 
{printfCTO driver error\n");} 

/* wait for acquisition 

7 

strcpy(hold, "OFF"); 
while(strcmp(hold, "ON")) { 

sprintf(IOmessage, "A7d20:AQ? HOLD"); 

if (IODriver(IOmessage) ! » NOERROR) 
{printf("IO driver error\n H );} 

sprintf(IOmessage, n A7620:\0 n ); 

if (IODriver(IOmessage) ! = NOERROR) 
{printf("IO driver errorXn");} 

fscanfClOChannel "%*m%*c %s",hold); 

fflushOEOChannel); rewind(IOChannel); 

} 

getNewRawToWfTransformQ; 
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/* Ask for Curve Data 

V 

sprintf(IOm ssag , B A7d20:CURVE?"); 
if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n B );} 
sprintf(IOmessage, B A7d20; B ); 
if (IODriver(IOmessage) ! = NOERROR) 

{printf("IO driver errorXn 11 );} 

/• 

fscanf(IOChannel, %*c %c %c\ header, &highByte, & lowByte); 

7 

/* Ask for and get raw data. Throw away checksum cr, & If 

7 

fread(RawData, sizeof(*RawData), 9, IOChannel); 
fread(RawData, sizeof(*RawData), (unsigned) RawSize, IOChannel); 
f flush(IOChannel); rewind(IOChannel); 
sprintf (IOmessage, B A7d20:AQ HOLD: OFF;*); 
if (IODriver(IOmessage) ! = NOERROR) 
{printfCIO driver error\n B );} 

return 

} 



static newVertSettings(param 
PARAMSPTR param; 

{ 

verticalSettings(param); 
/* User Parameters 

7 

sprintf (IOmessage, "A7d20:CH%ld VO:%e; B , param ->Settings. channel, 
Volts); 

if (IODriver(IOmessage) ! « NOERROR) 

{printfCIO driver error\n B );} 
sprintf (IOmessage, B A7d20:CH%ld POSI^e;", param -Settings, channel, 
Position); 

if (IODriver(IOmessage) ! - NOERROR) 

{printfCIO driver errorXn");} 
sprintf(IOmessage, B A7D20:CH%ld COUP: GND; B , param -^Settings, 
channel); 

/* input coupling */ 
if (IODriver(IOmessage) ! = NOERROR) . 

{printf( B IO driver error\n");} 
/* Digitizer constants 

7 

sprintf(IOmessage, °A7d20:CH2 INVrOFF,"); /• ch2 invert */ 

if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n B );} 
sprintf(IOmessage, B A7d20:CH%ld VA: OFF;", param ->Settings.channel); 

/* variable gain */ 
if (IODriver(IOmessage) ! = NOERROR) 

{printf( B IO driver errorXn");} - 
sprintf(IOmessage, "A7d20:TR MO: P-;°); /* trigger mode */ 

if (IODriver(IOmessage) ! » NOERROR) 

{printfCIO driver error\n");} 
sprintf(IOmessag , "A7d20:TR COUP: AC;"); /* trigger coupling */ 
if (IODriver(IOmessage) I « NOERROR) 
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{printf("IO driver error\n n );} 
sprintfflOmessage, B A7d20flOR CLJNT;"); /* horiz clock source */ 
if (IODriver(IOmessage) I « NOERROR) 

{printfClO driver error\n°);} 
sprintf(IOmessage, B A7d20:LO OFF; 0 ); /* long report form*/ 

if (IODriver(IOmessage) I = NOERROR) 

{printfCIO driver error\n a );} 
sprintf(IOmessage, "A7d20:TR SO: MO; B ); /* trigger source */ 

if (IODriver(IOmessage) ! = NOERROR) 

{printf("IO driver error\n");} 
sprintf(IOmessage,"A7d20.-CURS DEL: OF;"); /* delta cursors off •/ 
if (IODriver(IOmessage) ! = NOERROR) 

printfCIO driver error\n a );} 
sprintf(IOmessage, a A7d20:CS HM: ALLOF;"); /*high magnification off*/ 
if (IODriver(IOmessage) ! » NOERROR) 

{printfCIO driver error\n");} 
sprintf(IOmessage, B A7d20:CURS IK)*; /*high magnification off*/ 

{printfCIO driver error\n 8 );} 

return 

} 

static new HorizSettings(param) 
PARAMSPTR param; 

{ 

horizontal Settings(param); 

/* Send settings 
V 

/* User Parameters 

V 

sprintf(IOmessage, B A7d20:HOR TL%e; B , HorizTime); 
if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n");} 
sprintf(IOmessage, "A7d20:TR POSL%3.0f;", TrigPos); 
if (IODriver(IOmessage) ! = NOERROR) 

{printf( B IO driver error\n);} 
sprintf(IOmessage, "A7d20:TR SLOPE: %s;\ param -Settings. 
trigSlope); 

if (IODriver(IOmessage) 1 = NOERROR) 

{printfCIO driver error\n);} 
sprintf(IOmessage, B A7d20:TR LEVEL.-%e;°, param ->Settings. 

trigLevel); 
if (IODriver(IOmessage) ! =* NOERROR) 

{printfCIO driver error\n);} 

/* Open up the input channel (make a little noise) 

7 

sprintf(IOm ssage, B A7d20:CH%ld COUP: DC;", para->Settings. 
chann 1); 

if (IODriver(IOmessage) ! = NOERROR) 

{printf( B IO driver error\n);} 
/* Digitizer constants 

v 
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sprintf(IOmessage, a A7d20:DATA ENC: BIN; 8 ); /* data encoding*/ 

if (IODriver(IOmessag ) 1 « NOERROR) 
{printf( fl IO driv r error\n);} 

/* BLOSIM- controlled settings 
V 

sprintf(IOmessage, °A7d20:AQ MO: CH%ld; B , param -Settings. channel); 

/* acquisition mode */ 

if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n);} 
sprintf(IOmessage, B 7d20:DATA MEM: %ld B , param->Settings.channel); 

/* data memory */ 

if (IODriver(IOmessage) ! = NOERROR) 
{printf( H IO driver error\n);} 

return; 

} 

static getNewRawToWfTransformO 
{ 

/* Get number of points in waveform 

7 

sprintf(IOmessage, °A7d20:WFMPRE? NR B ); 
if (IODriver(IOmessage) ! = NOERROR) 

{printf("IO driver error\n");} 
sprintf(IOmessage, 9 A7d20: ,f ); 
if (IODriver(IOmessage) 1 « NOERROR) 

{printf( a IO driver error\n);} 
fscanf(IOChannel, %*c %d\ ARawSize); 

fflush^OChannel);rewind(IOChannel); 

/* Get horizontal offset 

V 

sprintf(IOmessage, B A7d20:WFMPRE? PT.OFF 5 ); 
if (IODriver(IOmessage) ! = NOERROR) 

{printfCIO driver error\n);} 
sp^intf(IOmessage, B A7d20: ,, ); 
if (IODriver(IOmessage) ! « NOERROR) 

{printfCIO driver error\n);} 
fscanf(IOChannel, ,l %*[~:] %*c %lf", &xZero); 
fflushpOChannel); rewind(IOChannel); 

/* Create global RawToWfTransfonn 
7 

RawToWfTransform.scale.x = HorizTime * 10.0 / Rawsize; 
RawToWfTransform.scale.y = 0.04 * Volts; 
RawToWfTransform.offsety = (- Position + 0.04) * Volts; 
RawToWf Transform. of f set x = -( xZero * RawToWfTransform.scale.x); 
return; 

static horizontalSettings(param) 
PARAMSPTR param; 

{ 

double p wrQ; 
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double tScale, tMantissa; 

/* HORIZONTAL SCALE; TimePerDiv <nr3> 
7 

HorizTime = (double) param->AcqRectextentx / 10.0; 
tScale » floor(loglO(HorizTime)); 

tMantissa = (int) (HorizTime / powr((double) 10.0, tScale) + 0,5); 
if (tMantissa <= 1.0) 

tMantissa = 1.0; 
else if (tMantissa <=2.0) 

tMantissa = 2.0; 
else if (tMantissa <=5.0) 

tMantissa = 5.0; 

else { 

tMantissa = 1.0; 
tScale = tScale + 1.0; 

} 

HorizTime = tMantissa * powr((double) 10.0, tScale); 

if (Horiztime > 20.0) HorizTime = 20.0; 

else if (HorizTime <=0.000000005) HorizTime = 0.000000005; 

/* DELAY SETTINGS: 

* The TrigPos value sent out to the 7D20 must be negative- 

* valued if it represents a time interval AFTER trigger. 

* The value must be positive (and <= 10) if the interval 

* represents a time BEFORE trigger. 

v 

TrigPos = - floor((double) param->AcqRectorigin.x / HorizTime ); 

if (TrigPos > 10.0) TrigPos - 10.0; 

else if (TrigPos < - 1500.00) TrigPose = -1500.0; 

/* Test to see if ifs contained 

v 

while ( 

((HorizTime * - TrigPos) > (double)param->AcqRectorigin.x) 

II 

((HorizTime * - TrigPos + HorizTime * 10.0) < 

((double) param->AcqRectorigin.x + (double) param- 

>AcqRect exten 
if (tMantissa = 1.0) tMantissa = 2.0; 
else if (tMantissa = 2.0) tMantissa = 5.0; 
else { tMantissa = 1.0; 

tScale = tScale + 1.0: 
} 

HorizTime = tMantissa * powr((double) 10.0, tScale); 

if (HorizTime>20.0) HorizTime = 20.0; 

else if (HorizTime<0.000000005) HorizTime = 0.000000005 
TrigPos =» - floor((double)param->AcqRectorigin.x/Hori 

if (TrigP s > 10.0) TrigPos » 10.0; 
lse if (TrigPos < - 1500.0) TrigPos = -1500.0; 

} 

return;/* might consider returning an err r if TrigP s outside rang */ 
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} 

static verticalSettings(parani) 
PARAMSPTR param 
{ 

double powrO; 
double vCenter; 

double heightPerDiv, vScale, vMantissa; 



vCenter = (double) param ->AcqRect extent y / 2.0 + (double) param - 

>AcqRecLorigin 

/* Probes can attenuate the incoming signal by factors of 
1, 10, and 100. When setting the Volts value, 
the probe factor must be included. When vertical scale 
information is obtained from a waveform preamble, however, 
no correction is necessary: 

vertical scale factor « Volts * probe factor 



/* VERTICAL SCALE; VoltsPerDiv <nr3> r 
V 

heightPerDiv = (double) param ->AcqRect extent. y / Probe / 10.0; 

vScale = floor(loglO(heightPerDiv)); 

vMantissa = heightPerDiv / powr((double) 10.0, vScale; 

if (vMantissa <=* 1.0) vMantissa - 1.0; 

else if (vMantissa o= 2.0) vMantissa = 2.0; 

else if (vMantissa <= 5.0) vMantissa = 5.0; 

else { vMantissa = 1.0; 

vScale = vScale + 1.0;} 

Volts = vMantissa * powr((double) 10.0, vScale); 

if (Volts > 5.0) Volts = 5.0; 

if (Volts <= 0.005) Volts = 0.005; 

/* VERTICAL POSITION: Position <nr2> 

V 

Position = -(vCenter/ Probe / Volts); 

/* Correction for window outside Position range 

v 

if ((Position > 10.2) 

y 

(Position < -10.2) 
II 

(((param ->maxSignal - param ->minSignal) / Volts) > 

OVERDRTVEFACTOR) 

) { 

if (fabs(vMantissa - 1.0) < 0.1) 

vMantissa = 2.0; 
else if (fabs(vMantissa - 2.0) < 0.1) 

vMantissa = 5.0; 

Is { 

vMantissa = 1.0; 
vScal = vScale + 1.0; 
} 

Volts = vMantissa * powr((double) 10.0, vScale); 
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Position = -(vCenter / Probe / Volts); 

} 

return 

} 

static makeWaveform(wave, start, stop, param) 

PARAMSPTR param; 

WAVEFORM *wave; 

int start; /* first index into RawData */ 

int stop; /* last index into RawData */ 

{ 

POINT aPt, bPt; 

int rawPtr, arrPtr = 0; 

float *arr; 

char *malloc0; 

char *strcpy0; 

arr = (float *) arr ptrfwave); 

for (raWPtr = start; rawPtKstop + 1; rawPtrH-) { 

aPty = (float) ((RawData[rawPtr] & 0377) - 128); 
aPtx = 0.0; 

transfonn(&RawToWfTransform, &aPt, &bPt); 
arrfarrPtn-f] = bPLy, 

if (param ~>maxSignal <bPty) param ->maxSignal « bPty; 
else (param ->minSignal > bPty) param ->minSignal « bPty; 

} 

/* x-axis scaling and offset 

v 

dim scale(wave,0) = (double) RawToWfTransform. scale, x; 

dim_offset(wave,0) = (double xZero - start; 

if ((dim__units(wave,0) = (char *) malloc((unsigned) 8)) = NULL) 

printf( n malloc unable to allocate space\n"); 
strcpy(dim_ units(wave,0) t "Seconds"); 

if ((tup_jinits(wave,0) = (char *) malloc((unsigned) 6)) = NULL) 

printf(°malloc unable to allocate space\n B ); 
strcpy(tup_units(wave,0), "Volts"); 
return; 

> 

static waveformLimits (param, pStart, pStop) 
PARAMSPTR param; 
int *pStart, *pStop; 

{ 

POINT aPt; 
POINT bPt; 

aPtx = param ->AcqRectoriginx; 

aPty - 0.0; /* ... a placehold r */ 

inverseTransform(&RawToWfTransform, &aPt, &bPt); 
•pStart = bPtx; 
if (*pStart < 0) *pStart » 0; 

aPtx » param->AcqRectorigin.x + param ->AcqRectextentx; 
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aPty - 0.0; /* ... a placeholder */ 

inverse Transform(aRawToWfTransform, &aPt, &bPt); 

♦pStop = (int) (ceil(bPtx)); 

if (*pStop > = RawSize) *pStop = RawSize - 1; 

return; 

} 

static dataToSmaUtalk(param t wave) 

PARAMSPTR param 
WAVEFORM *wave; 



{ 



float scaleFactor; 
float offset; 
short totalPoints; 

/* Print out header information to the response file in the following 

* order 

* 1. Response Class (string) 

* 2. Current Block Name (string) 
7 

fprintf(responseFile, B %s\n" f "digitizer"); 
fprintf (responseFile, °%s\n", param ->title); 

/* Print out waveform information to the response file in the 

* following order 

* 3. maximum Signal Value 

* 4. minimum Signal Value 

7 

fwrite((char *)(&(param->maxSignal)),sizeof(float), 1, responseFile); 
fwrite((char *)(&^aram->minSignal)),sizeof(float), 1, responseFile); 

/* Print out waveform information to the response file in the 

* following order 

* 5. Horizontal Units (string) 

* 6. Vertical Units (string) 

* 7. Horizontal Scale Factor (binary float) 

* 8. Horizontal Offset (binary float) 

* 9. Total No. of Points (binary short) 

* 10. Array Data (binary floats) 

7 

fprintf(responseFile, "%s\n°, dim_units(wave,0)); 
fprintf(responseFile, "%s\n% tup_units(wave,0)); 

scaleFactor =» (float) dim_scale(wave,0); 

fwrite((char *)(&scaleFactor), sizeof(float), 1, responseFile); 

offset = (float) dim_offset (wave,0); 

fwrite((char *)(&offset), sizeof(float), 1, responseFile); 

totalPoints = wave__size(wave); 

fwrite((char *)*&totalPoints), sizeof(short), 1, resp nseFile); 

print_wf_arr(wav ,r sponseFil ); 

/* And finally, END, to finish things off 



EP0 295 760 A2 .*\.*\ 

* » * * * 

** * - > 

7 

fprintf(responseFile, "%s\n B , "END"); 
return; 

} 

/• 

transform: 

apply the transform to window cordinates 
giving viewport coordinates. 

v 

static transform(pTransform, pPoint, pResultPoint) 

WINDOWTRANSFORM • pTransfonn; 

POINT * pPoint 

POINT * pResultPoint; 

{ 

pResultPoint ->x « pPoint ->x * pTransform->scale.x + 

^Transform ->offsetx; 
pResultPoint ->y = pPoint ->y * pTransf orm - .scale, y + 
pTransfonn ->of f set y; 
return; 

/• 

inverseTransfonn; 

apply the transform to viewport coordinates 
giving window coordinates. 

v 

static inverseTransform(pTransform, pPoint, pResultPoint) 

WINDOWTRANSFORM * pTransfonn; 

POINT * pPoint 

POINT * pResultPoint; 

{ 

pResultPoint ->x = (pPoint->x - 

pTransfonn ->of f set x) / pTransfonn ->scale.x; 
pResultPoint ->y = (pPoint ->y - 

pTransfonn ->of f set y) / pTransfonn ->scale.y, 

return 

} 
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APPENDIX C - - Program Listing for Signal Analysis function: poiars 

^*** ******* *************************** ************************************ 

poIarsO 

*************************************** ***********************************y 

#include <stdio.h> 
#include "typch" 
#include "spin" 
#include "sp.h" 

extern FILE *responseFile; 
extern FILE *commandFile; 

/* typedef parameter and state */ 
typedef struct { 

int dummy; 

}STATE, *STATEPTR; 

typedef struct { 

UNIT units; 
BOOL unwrap; 
float delay; 
char name[80]; 

} POLARPARAM, *POLARPPTR; 
/******************.***********.**********.******.*********..„******„**** 

star_polarsO 
inputs and Outputs are waveforms. 

********************************** *******************+************ ********* 

star poiars 
CHAINPTR info; 

{ 

int polarsO; 

POLARPPTR polarp; 

char blockname[NAMELENGTH]; 

POINTER para_allocateO; 

char *strcpy0; 

char string[20] 

/*printf("Instar-polar\n");*/ 

strep y (blockname, info->blockname); 

/*fprintf(info->querry_file, "Enter one of the following number 

representation of phase 
fprintf(info->querry_file, B l. RAD\n2. GRAD\n3. DEGREEXn");*/ 
fscanf(info->inputfile, n %s B , string); 
/* printf("string = %s\n D , string);*/ 
if (IstrcmpCrad", string)) 

polarp ->units =* 0; 
else if (lstrcmp( !t grad",string)) 

polarp ->units = 1; 
else if (!strcmp("degree a , string)) 

polarp ->units = 2; 
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fprintf(info->save_file > ,! %d ,, f polarp->units); 

/♦fprintfpnfoo^uerry^file/Enter boolean (0, 1) to indicate whether 

th phase wanted 
fscanf(info->inputfile, l, %s ,! , string); 
if (!strcmp("wrap", string)) 

poiarp->unwrap ~ 0; 
else if (IstrcmpCunwrap 0 , string)) 

polarp ->unwrap = 1; 
fprintf(info->save__file,' ! %d", polarp ->nnwrap); 
fprintf(info->querry_file, "Enter delay to specify liner varying of 

phase adjustment^") 
fscanfpnfooanputftte/^&f", &polarp->delay); 
fprintf(info->save__file, *%F, polarp ->delay, 
info->no input » 2; 
info->no output » 2; 

star__setup (inf o, polars, (char *)polarp,sizeof(POLARPARAM)); 
return (0); 

} 

polarsO 

polars(pparam,size,pstate) 
POLARPPTR pparam; 
int size; /* size of parameter storage */ 
STATEPTR pstate; 



{ 

SAMPLE x, y, mag sample, phase, sample; 

char *alloc_state M _var(); 

WAVEFORM *magw, *phasew; 

ERRORTYPE create ._wf(), polarO, errorcode; 

INDEX wdimp]; 

int tupletype[4]; 

int len__output_fifoO; 

int maxl__output-fifoO; 

char *name; 

char *malloc(); 

char string[20]; 



/* on first call only, initialize and check for errors */ 
if (pstate — NULL) { /* first call */ 

/* allocate state variable storage */ 

pstate + (STATEPTR) aUoc_state_var(l,sizeof(STATE)); 

/* error if parameter not set by topology */ 

/* error if not connect d to two output fifo */ 

if(no_output_fifosO ! = 2) 
return(2); 
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/* error if not input fifo */ 

if(no_input_fifos() ! = 2) 
retum(3); 

} 

/* first make sure the output fifo is not full before we get a sample 
from and input fifo */ 

if (len_putput__fifo(0) = maxl__output_fifo(0)) 

retum(0); /* output fifo full */ 

if (len_putput_fifo(l) =* maxl_output_fifo(l)) 

return(O); /* output fifo full */ 

/* now get the sample values from the input fifo */ 

if ((get(0m, &x) = 0) && (get(l, &y) 0)){ 
fprintf(responseFile, "^Xn", "invert"); 
fprintf(responseFile, ^Xn", pparam->name) 
fflush(responseFile); 
fscanf(commandFile, m %& 9 9 string); 
if (strcmp(string, "@")) { 

printfCWrong signal - %& received by polarsV, string); 

fflush(stdout); 

} 

if (x->type != WAVE_SAMPLE || y->type ! = WAVE_JS AMPLE) 
printfCThe type of the smaple received by polarsO was 
invalid\n"); 
tupletype[0] = tup_type(x->uvaLwave, 0); 
wdim[0] = dim_Jen(x->uval,wave, 0); 

if ((errorcode = create_wf(wave_dim(x->uvaLwave), wdim, wave. 
tuple(x ->uvaL wave) 
printf( B create_wf 1 in polar, reports ERRORCODE %2d \n", 
errorcode); 

if (samp - alloc(&mag sample) ! = NOERROR) 

printf(°samp_allocO was unable to allocate SAMPLE space\n"); 
mag sample ->type = WAVE_JSAMPLE; 
mag sample >uvaL wave = magw; 

if ((errorcode — create_wf(wave__dim(x->uvaLwave), wdim, 

wave tuple(x ->uvaL wave) 

printf("create_ wf2 in polar, reports ERRORCODE %2 \n\ 
errorcode); 

if (samp_alloc(&phase_sainple) ! = NOERROR 

printf( H samp_allocO was unable to allocate SAMPLE space\n"); 
phase_sampie->type = WAVE_S AMPLE; 
phase__sample ->uvaL wave = phasew; 

if((errorcode=polar(x->uval.wave, y->uvaLwave, pparam->units, 
pparam->unwrap, (d 
printf("p lan rep rts ERRORCODE %2d\n", errorcod ); 
/*if ((name = (char *)(malloc((unsigned)(strlen(title_ptr(x-> 
uvaLwave)+8)+10)))) 
printf("malloc couldn't allocate enough space \n*); 
sprintf(name, "POLAR OF%s",(title_j)tr(x->uval.wave)+7)); 
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title_ptr(magw) = title__ptr(phasew) = name;*/ 
dim_scale(magw, 0) = dim_scale(phasew, 0) = dim_scale(x 
->uvaLwave, 0); 

r 

* Set the Horizontal axis units for the magnitude and phase 

* waves 

7 

dim^unitsCmagw, 0) = dim_units(phasew, 0) = "Hertz*; 

/* 

* Set the vertical axis units for the magnitude and 

* phase waves 

/* 

tup_units(magw, 0) = "Volts"; 
switch(pparam ->units) 

{ 

case 0: tup__units(phasew,0) = "Radians"; 
break; 

case 1: tup__units(phasew,0) = "Grads"; 
break; 

case 2: tup_units(phasew,0) = "Degrees"; 
break; 

default; tup_units(phasew,0) = "Unknown"; 

} 

if (len_j>utput_fifo(0) ! = maxl_putput_fifo (0)) 

put (0, &ma g s ample) /*put sample onto output fifo*/ 

if (put(l, &phase_jsample) ! = 0) /*put sample onto output fifo*/ 
return(O); /* output fifo full */ 

} 

return(0); /* input fifo empty */ 
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NAME 

polar 
PURPOSE 

Converts rectangular coordinates to polar coordinates. 

SYNOPSIS 

#include "tekspd.h" 

ERRORTYPE 

poIar(reaI, im, units, unwrap, delay, mag, phase) 

WAVEFORM *real, ♦im; 
UNIT units; 
BOOL unwrap; 
double delay; 

WAVEFORM *mag, *phase; 

DESCRIPTION 
real: 

Pointer to die waveform containing x-coordinate or real number data. 
im: 

Pointer to the waveform containing y-coordinate or imaginary number data. 
units: 

Indicates whether phase should be calculated in radians, degrees, or grads. 
unwrap: 

Boolean that, if true, indicates that the phase data will be unwrapped. 
delay: 

Specifies a linearly varying phase adjustment 
mag: 

Pointer to the output waveform containing magnitude data. 
phase: 

Pointer to the output waveform containing phase data. 

polar converts the data in real and im into magnitude data and phase data to be stored in mag and phase, 
respectively, using the formulas below: 

mag_arr[i] = Vreal_arr[i] 2 + im_arr[i] 2 

phase_arr[fl=arctan + n unwrap_adjustment M - 2n-delay i 



where 

mag_arr[i], phase_arr[f], real_arr[i], and im_arr[i] are waveform array values at the index i. 

"unwrap_adjustment" is 0 if unwrap is FALSE, else it is set to ±mr where n is the unwrapping 
value used to eliminate the discontinuities at the ±rc phase boundaries. 

If either of the source waveforms, real or im, is die same as a target waveform, that source waveform is 
overwritten with the output data. If the waveform arrays are different sizes, the target waveform arrays 
will only be valid up to the length of the shortest of these arrays. If either mag or phase is a NIL pointer, 
the data for that waveform is simply not returned. 



1 



POLAR ( ) 



APPENDIX C 



POLAR ( ) 



units is defined by one of three predefined keywords: RAD for radians, GRAD for grads, or DEGREE for 
degrees. 

If unwrap is true, the phase data, which originally falls between tc and -a, is unwrapped modulo In to 
eliminate the discontinuities at n and -re and give continuous phase. 

The delay parameter causes a linearly varying phase component whose slope is lie-delay to be subtracted 
from the phase after rectangular-to-polar conversion. 

Both source waveforms and at least one target waveform must be valid. One target waveform pointer may 
be NIL. Information is taken from the first dimension and is placed in the first dimension. The data type 
information is taken from the first tuple. 

The function returns an error code (as defined in the spdh include file) indicating whether or not it was 
able to execute correcdy. 



2 
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APPENDIX D — Netlist Format 



The format of the netlist passed to BLOSIM is: 

< executable function name> <block name> 
<parameter 1> 
<parameter 2> 



<executable function name> <block name> 
<parameter 1> 
<parameter 2> 



Connect 

<source block name> <output port> <dest block name> <input port> <queue length> 
<source block name> <output port> <dest block name> <input port> <queue length> 



END 



where : 



executable function name 

name of the function in the executable function library 

block name 

name of the block as it appears on the block diagram 

Connect 

keyword denoting the start of the connection specification 

source block name 

name of the block (as it appears on the block diagram) of 
a block generating output data 

output port 

number of the output port of the block generating the data 

dest block name 

name of the block (as it appears on the block diagram) of 
a block- receiving input data 

input port 

number of the output port of the block receiving the data 

queue length 

length of the queue connecting blocks 

END 

denotes the end of the netlist 
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APPENDIX D — Example Natl. at 

BfgSOlO fg5010B 
SINE 
1.0 

1200.0 
0.0 
50,0 
AfgSOlO fgSOlOA 
SINE 
1.0 

1000.0 

0.0 

50.0 

ps5010 power Supply 
15.0 
0.4 
15.0 
0.4 

axnModulator amModulator 
A7d20 7d20A 

6.19197e-5 

-8.17227 

0.00317337 

15.2311 

0.0 

PLUS 

1 

6.16 

-7.2 

YES 
rf fts rfft 
polars polar 

rad 

wrap 

0.0 
sink sink 
waveprint graph 
Connect 

fg5010B 0 amModulator 0 1 

fg5010A 0 amModulator 1 1 

powerSupply 0 amModulator 2 1 

amModulator 0 Jd20A 0 1 

7d20A 0 rfft 0 1 

rfft 0 polar 0 1 

rfft 1 polar 1 1 

polar 0 graph 0 1 

polar 1 sink 0 1 

END 
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APPENDIX E. The definition of SAMPLE in the 
Experiment Manager 



/* 

*SAMPLE is 

the bl 
*Experiment 
*/ 

struct samp 
int type; 
union -C 
short 
int 
1 ong 
■Float 
double 
char 

WAVEFORM 
> uval ; 



the type of the object passed between 
ock functions of the 
Manager. 

le I 

/* defined type of sample */ 
/* 7 possible sample types */ 



sval 
i val 
lval 
f val 
dval 
*str 



ng; 



#wave; 



/* short integer sample 
/* integer sample 
/* long integer sample 
/* floating point sample 
/■* double precision sample */ 
/* character string */ 
/* pointer to waveform */ 



*/ 
*/ 
*/ 
*/ 



typedef struct sample ATS AMPLE; 
typed ef ATS AMPLE *SAMPLE; 



/* 

* Def 
*/ 

#def i 
#def i 
#def i 
#def i 
#def i 
#def i 
#def i 



ined types for the 
ATSAMPLE. 

ne SHORT_SAMPLE 1 
ne INT_SAMPLE 2 
ne LONG_SAMPLE 3 
ne FLQAT_3AMPLE 4 
ne DEL_SAMPLE 5 
ne STR I NS_5AMPLE 6 
ne WAVE_SAMPLE 7 



'type' field of structure 



/* short integer sample */ 
/* integer sample */ 
/* long integer sample *•/ 
/* floating point sample*/ 
/* double precision */ 
/* character string */ 
/* waveform pointer */ 
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APPENDIX P. A Listing of a Typical Block Function 
#include <stdio.h> 

#include "type.h" /* contains the definition of 
SAMPLE */ 

/* 

♦Declare the number of block function run-time 
input and outputs, 

*/ 

#define NUHINFUTS 1 
tdefine NUMOUTPUTS 1 

/* 

♦Declare the Smalltalk-to-C and C-to-Smalltalk 
pipes as external 

*/ 

extern FILE *responseFile; 
extern FILE *commandFile; 

/* 

♦Define the parameter and state storage areas. 

typedef struct { 

int dummy; /* no state variables needed 



} STATE, *STATEPTR; 



typedef struct { 
int inFromPipe ; 



char name [80]; 
} PARAM, *PARAMPTR; 



/* integer parameter 
to be read from the 
"commandFile" pipe 

/* space for the block 
function 1 s name 



/********************** **************************** 
* 

*star_example — this function is the block 

* function driver routine for the 'example' 

* block function. The driver is responsible 

* for allocating and initializing the data area 

* for the block function, reading any 

* parameters from the Smalltalk-to-C pipe and 

* defining the number of run-time inputs and 

* outputs ♦ 
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♦inputs : 
* 

* - info — a pointer to the CHAIN data structure , 

* which is a repository for information 

* about the block function. 

* See type.h for the definition of the 

* CHAIN data structure. 
* 

♦returns : 

* 0 indicating successful completion. 
* 

♦effects: 
* 

* The parameter area for the block function is 

* allocated and the number of inputs and 

* outputs are installed in the 'info' data 

* structure . 
* 

♦exceptions : 

* none 
* 

*********************^ 

star_example ( info ) 
CHAINPTR info; 



int example ( ) ; 

PARAMPTR par am; 



char 
char 



♦para_allo- 
cate(); 

♦strcpy(); 



/♦ the block function 

routine 
/♦ pointer to the 

parameter area 

/♦ parameter area 

allocation routine 
/♦ string copy function 



♦ Allocate the block function's data area 
and install its name. 

*/ 

param = (PARAMPTR) para_allocate 

(sizeof (PARAM)); 
strcpy (param->name, inf o->blockname) ; 
/* 

♦ Read a parameter from the commandFile pipe 

and store it in the 

♦ data area. 

*/ 

f scanf ( commandFile , " %d " , 
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&param->intFromPipe) ; 

/* 

* This block function has one input and one 
output as defined above. 

*/ 

info->no_input = NUMINPUTS; 
info->no_output = NUMOUTPUTS; 

/* 

* star_setup() stores pointers to the 

example () function and the 

* data area . The pointer to example ( ) 

is used later to 

* execute the block function routine. 

*/ 

star_setup ( info , example , ( char * ) param , 
sizeof (PARAM)); return (0) 

> 



J ************************************ **************** 
* 

* example — this function is the 'example* block 

* function routine. It contains (or calls) the 

* functional block or code that defines the 

* semantics of this module. It is responsible 

* for allocating the state variable storage and 

* checking for possible parameter errors. 
* 

* This example block function has one input 

* (where it received a SAMPLE) and one output 

* (where it can send out a SAMPLE). It also 

* interacts with the Smalltalk process to 

* request animation and display of error 

* messages. For illustration, it also sends a 

* keyword recognized by the server out the 

* "responseFile" pipe to the Smalltalk process. 
* 

* inputs: 

* param — a pointer to the data area 

* size — the size of the data area 

* pstate — a pointer to the state variable 

* storage area 
♦returns : 

* Non-zero integer error code in case 

* of an error; else 0. 
* 

*ef fects: 

* Block animation will result from the call 



EP 0 295 760 A2 



APPENDIX F 



to 1 invertBlock( ) ' . 
A sample may be received and one may be 
output . 

The state variable storage area will be 

allocated upon the first 
call to example ( ) . 

A keyword is sent along the "responseFile" 
pipe to the Smalltalk process. 



* 
* 
* 
* 
* 
* 
* 
* 
* 

* exceptions : 

* The following are error conditions and result 

* in non-zero return codes: 
* 



The 'size 1 parameter does not match 
the size of the parameter data area. 
The number of inputs or outputs 
(fifos) is not as expected. 
Attempts to access an empty input fifo or 
write to a full one are not typically error 
conditions . 



* 

* 
* 
* 

*********************^ 
example ( par am , s i z e , ps t ate ) 



PARAMPTR 
int 

STATEPTR 
{ 

SAMPLE 
SAMPLE 
char 
int 

int 



par am; 

size; 

pstate; 



/* sample sent out 

the output * 
/* sample received 

at the input * 
*alloc_state_yar( ) ; /* state variable al- 
location routine * 
len_output_f if o ( ) ; / * returns length 

of the output 
fifo * 
maxl_output_fifo( ) ; /* returns max. 

length of output 
fifo * 



outputSample ; 
input Sample; 



/* 

* If this is the first call to this block 

* function routine, allocate the state variable 

* storage area and check for errors . 
*/ 

if (pstate == NULL) { 
/* 

* Allocate the state variable storage area. 
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V 

pstate = (STATEPTR) alloc_state_var 
( 1 , sizeof (STATE) ) ; 

/* 

* Check the size of the parameter area. 
*/ 

if (size 1= sizeof (PARAM) ) 
return(l) ; 

/* 

* This block function has one input 
and one output as defined above. 

*/ 

if (no_input_fifos() 1= NUMINPUTS) 
return { 2 ) ; 

if (no_output_fifos() != NUMOUTPUTS) 
return ( 3 ) ; 

} 

/* 

*Make sure the output fifo is not full before 
we get a sample. 

*/ 

if ( len-output-f if o ( 0 ) — maxl_output_f if o ( 0 ) ) 
return(O); 

/* 

* Get the sample (if any) from the input fifo. 
*/ 

if ( get ( 0 , &inputSample ) — 0 ) { 

/* 

* Request the Smalltalk process to 

* set the display block to reverse video. 

*/ 

invertBlock(param->name) ; 

/* 

* This block function expects an integer 
sample so it checks the type. 

/* 

if (inputSample->type != INT_S AMPLE ) 

errorLog(param->name, "The type of the 

sample received 
by example ( ) 
was invalid") ; 

/* 
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* Allocate space for the sample to be sent as 
output . 

*/ 

if (samp_alloc(&outputSample) 1= 0) 

errorLog(param->name, M samp_alloc( ) was 

unable to 
allocate SAMPLE 
space " ) ; 

/* 

* If an integer sample is received, the output 

* sample is set to integer 0. 

****** This is the point where other ****** 
****** application code would typically ****** 
****** b e inserted. ****** 

*/ 

outputs ample- > type = INTJSAMPLE; 
outputSample->uval.ival =0; 

/* 

* Send out the result 

*/ 

if ( put ( ) , &outputSample ) 1=0) 

return (0); /* output fifo full */ 

/* 

* Send a keyword out the responseFile pipe 

* to the Smalltalk process. 

*/ 

f print f (responseFile, w %s n , "scalar" ) ; 
} 

return(O); /* input fifo empty */ 
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APPENDIX G: Signal Viewing Variables 

These are the variables used in the operation of signal viewing interface to a digitizer. 
Interface defining and operating variables 



defauKAcqRect 



screen Red 



dtsplayTransformatlon 



acqRect 



zoomOutFactor 



minZoomRect 



Rectangle 

origin x: 0.0 start time 
origin y: -5.0 lowest voltage 
comer x; 0.01 end time 
corner y: 5.0 highest voltage 

Rectangle from 'zoom in' function 

origin x: 0.0 corresponds to start time 
origin y: -5.0 corresponds to lowest voltage 
corner x: 0.01 corresponds to end time 
comer y: 5.0 corresponds to highest voltage 

WindowingTransfonnation 

scale: scale factors for x and y dimensions 
translation: offset factors for x and y dimensions 

Rectangle 

origin x: user-specified start time 
origin y: user-specified lowest voltage 
comer x: user-specified end time 
comer y: user-specified lightest voltage 

Point 

x: factor by which to expand acqRect horizontally 
y. factor by which to expand acqRect vertically 

Rectangle 
origin: 0@0 
extent 10@10 

Minimum size, in screen units, of rectangle for 'zooming in.' 
These coordinates are entirely arbitrary and should be dictated 
by the application area addressed. 



Digitizer defining variables 



vlables 



rangeTable 



mlnOffset 



Collection 

Contains following four variables which define a digitizer for vertical settings 
Collection 

Permissible voltage range settings arranged from smallest to largest 
Number 

Lowest offset (as percentage of range) setting allowed 
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maxOffset 



offsetRes 



Number 

Highest ffset (as percentage of range) setting allowed 
Number 

Resolution of offset setting 



hTables 

samplelntervalTable 
mlnDelay 
maxDelay 
maxSamples 



Collection 

Contains following four variables which define a digitizer for horizontal settings 
Collection 

Permissible sample interval settings arranged from smallest to largest 
Number 

Lowest delay setting allowed 
Number 

Highest delay setting allowed 
Number 

Maximum value 0/ samples that may be acquired. 



Calculated digitizer settings 



range 



offset 



samplelnterval 

delay 

samples 



Number 

an element from rangeTable in volts peak-to-peak 
Number 

in ± percent of range 
Number 

an element from SampleRateTable, in seconds 

Number 
in samples 

Number 

number of samples to be acquired 
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APPENDIX H 

This is the method (written in the Smalltalk-80 programming language) for caluclating 
the vertical settings to be sent to a digitizer. 

verticalSettings: acqRect tables: vTables 

"This method calculates range and offset settings tor a digitizer defined In 

vTabtes for a user-specified acquistion rectangle, acqRect' 

| rangeTabla offsetMin offsetMax i range offset result offsetRes | 

"vTabtes Is a dcttonary with 4 entries. U defines a algitlzer for establishing vertical settings. 
The table's entries are; 

rangeTable • a collection of vertical ranges, ordered smallest to largest 

offsetMin <- minimum value for offset 

offsetMax «- maximum value for offset 

offsetRes «- resolution with which offset may be specified. 

The following temporary variables are unpacked from vTabtes for darby? 

rangeTable <- vTables at: 1. 
offsetMin «- vTables at: 2. 
offsetMax «- vTables at: 3. 
offsetRes *- vTables at: 4. 

1 4— 1 . "a pointer into rangeTable* 

[ "Select a range from rangeTable* 

range <- rangeTable at: i. 

"Cafcufate an offset, as a percentage of the current range, such that the offset 
Is the center of the acqRects vertical component or the minimum or maximum 
aBowed offset value.' 

offset <- (((acqRect top + acqRect bottom) / 2.0) / range * 100.0) truncateTo: offsetRes. 
offset <- (offsetMin max: offset) min: offsetMax. 

"Test to determine whether: 

1) the rangeTable has been exhausted, or 

2) the range and offset settings can be combined to bracket the 
acqRects vertical component 9 

i >m rangeTable size 

or [(acqRect top) >» ((range * (offset / 1 00.0)) - (range / 2.0)) 

and: [(acqRect bottom) <- ((range * (offset / 1 00.0)) + (range / 2.0))]]] 
whfleFaise:[i«-i + 1], 

'Transcript 

show: ((range * (offset / 100.0)) - (range /2.0)) prmtStringfcbfrb; 
show: ((range * (offset / 100 J>)) + (range/ 2.0)) printStnh^-cr; 
tabphow: 'RANGE: \ range prints tringpr. 
tab^how: XXTSET: \ offset printSlnngxncr." 

result <- OrderedCoIlection new: 2. 
result addLast: range; 

addLast: offset. 
T result 
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APPENDIX I 

This is the method (written in the Smalltalk-80 programming language) for caluclating 
the horizontal settings to be sent to a digitizer. 

horizontalSettings: acqRect tables: hTables 

"This method calculates samplelnterval, delay and samples settings for a t8gtil2ef defined In 
hTables tor a user-specified acqubtton rectangle, acqRect" 

| samplelntervaiTable minDelay maxDelay maxSampIes i samplelnterval delay samples result | 

m hTables is a coffecSon with tour entries. It defines a dglttzer tor establishing horizontal 
settings, The table's entries are: 

samptetntervafTable - a collection of available sample rates, ordered from shortest to longest. 
minDelay - the minimum delay value (with respect to a trigger event) t 
maxDelay - the maximum delay value, 

maxSampIes - the maximum number of samples that may be acquired 

The following temporary variables are unpacked torn hTables tor clarity? 

samplelntervaiTable <- hTables at 1. 
minDelay <- hTables at: 2. 
maxDelay <- hTables at: 3. 
maxSampIes «~ hTables at: 4. 

i «— 1 . "a pointer into the samptelntervajTable" 

[ 'Select a sampSng rate, samplelnterval, torn samptetotervafTable" 

samplelnterval <~ samplelntervaiTable at: L 

" Calculate delay as the number of sampTtng intervals (after a trigger event) to wait before samp&ig. 
Delay must obey the restriction: minDelay <* delay o maxDelay" 

delay <- (acqRect left / samplelnterval) floor asFbat."us© next lowest toteger number of sample times 9 
delay «- (minDelay max: delay) min: maxDelay. 

'Calculate the number of sample points, samples, from the 5rst sampBng time to the sampling point 
at or 1 past the latest (or right) edge of the acquisition window (the value is 1 greater than the 
number of sampSng intervals). Samples must obey the restriction: samples <- maxSampIes." 

samples «- ((acqRect right - (delay * samplelnterval)) / samplelnterval) ceiling asFloat + 1.0. 
samples «- samples min: maxSampIes. 

'Test to determine whether: 

1) the samplelntervaiTable has been exhausted, or 

2) the acquisition rectangle*s latest (or right) edge is less than or equal to the delay ante plus 
the eTgNxer window's width (the Acquisitbn window's oar&est (or left) edge is guaranteed to 
be within the olginzer's window by the delay calculation)* 

i >« samplelntervaiTable size 

or: [acqRect right <- ((delay * samplelnterval) + ((samples - 1.0) * samplelnterval))] 
whileFalse: [ i *- 1 + 1 J. 

'Return a collection with samplelnterval, delay, and samples" 

result <- OrderedCoIIection new: 3. 
result add Last: samplelnterval; 

addLast: delay; 

add Last: samples. 
T result 
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APPENDIX J 

Tlwsse are the key Stnamak-SO fot pKUaBy , ^ ^ ^ ^ ^ 



Tto^ wo*^ ^ for ^ ^ ^ ^ t ^ fc controlling , power 

ps «- PowerSuppiy new. 

ps constraints: (OrderedCollectfon 

with: (0.05@ao comer: 0.4@32.0) 

with: (0.4@0.0 corner 0.75@15.0)). 

PowerSupplyView openOn: ps 

PowerSuppr/Controller methodsFor: Interactive settings' 
redButtonActlvlty 

Decide which operating point to adjust 

Select the operating point nearest the default cursor when theoutton was pushed. ' 
I myPosition cursorPositwn d1 d2d3 | 

cursorPosition *- Sensor cursorPoint 

myPosition <- (view displayTransformation applyTo: model asPoint) rounded. 

nndoJstances from default cursor position to: 
x operating point cursor mid-point 
y operating point cursor mid-point 
combined operating point ' 

d3 - curwrPoshfan d£ SXET * @ ( b ° tt ° m + myPosillon ' *-°»- 

TtoiMhortB* and perform appropriate operation.- 

d1<d2 

iTrua: [d1 < d3 

ifTrue: [self yPointOperatibn] 

ifTrue: [seff xPointOperation] 

ifFalse: [self combinedPointOperaiionlJ 
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TOs method provides for the interactive adjustment of the combined operating point 

comblnedPolntOporatlon: view 

•Displays x cursor from point to graticule which track 
the sensor point until the red8uttonls clicked' 

IscreenPt oldScreenPt screenConstraints oldRect a b oldXCursor oldYCursor ( 

"Go/ combined operating point in screen coonSnatas.' 

screen* «- oWScreenPt <- view displayTransform: model asPoint. 

•Blank out cursor and move it to the combined operating point* 

Cursor blank show. 

Sensor cursorPoint: screenPt 

~Mate forms for the x and y cursors. " 

oldXCursor*- (Form 

extent: ((xCursor translateBy: oldScreenPt) 

extent: ((yCursor translateBy: oldScreenPt) 

intersect: view insetDisplayBox) extent) black. 

screenConstraints «- screenConstraints: view di transformation. 

oldRect - ^en^raints detect: fpc I x containsPoint: screenPt) 
tfNone. [self error 'self not within constraints"). 

"While the red button Is pressed, adjust the combined operating point • 

[Sensor redButtonPressed) whileTrue: 
[screenPt «- Sensor cursorPoint 
screenPt - oldScreenPt 

(okJRect containsPoint: screenR) 

oldRect «- screenConstraints 

detect: [a | x containsPoint: screenPt] 

screenPt screenPt + ({screenPt extent: 1 @ 1 ) 

amountToTranslateWrthin: oldRect) 
Sensor cursorPoint: screenR 
oldRect]]. 



APPENDIX J 
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backgrounds (a variant of a standard Smaffta/kSO mathod. vBo and yA, «■ 

yBfl oWYCursor moveNewForm: (oldYCureor - 

((Form extent: (a <- ((yCursor translateBy: screenPt) 
to- a origin*** lnsetDisp,a y Box )) "rtent) black)) 
restoring: yBg. 
xBg «- oldXCureor moveNewForm: (oWXCureor 

((Form extent: (a <- ((xCursor translateBy: screenPt) 
to- a arigir^ ^DBP'ayBox)) extent) Wade)) 
restoring: xBg. 

"Paint up tfio new dglta/ raadout. " 

self updateReadouu screenPt. 
oldScreenPt <- screenPt]]. 

^ESS!?* (Vi9W '—transform: screenPt, 
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Table 1 - Signal Processing block functions 





JHorfr Ftin^M 


Input* 








add 


«dd 


Lwaveform 


^waveform 


none 


The Input wareformj are 
added etement-br-element. 


l.WSTefOTBi 


Lwareform 


Tbe scalar Is added to each 
element of the Input wareform. 


1 sftilir 


1 trail r 


The Input scalar* are added. 


difT 


dlffe 


W ID 


t * 


Limpulse 

TCT9n» length. 


Tbe Input waTeform Is 


dlv 


dlr 


Lwuveform 
2. wareform 


L waveform 


none 


jUfftrtntlitrf, 

WaTeform 1 Is divided by 
wareform 2 on an element-by- 
dement basis. 


Lwareform 
2jcalar 


*■ w«it cs win 


Each element of the Input 
wareform is divided by the 
scalar. 


Lscalar 


Lacalar 


Scalar lis divided by scalar 2. 


Integrate 


In teg 


Lwarefonn 


Lwareform 


none 


The Input waTeform Is 


mult 


mult 


Lwareform 


lwareform 


Bone 


Interned, 

The Input wareforms are 
multiplied dement*by-elemenL 


Lwareform 
^scalar 


Lwareform 


J£acn element of the Input - 
waveform Is multiplied by the 
scalar. 


Lscalar 
2jcalar 


Lscalar 


Tbe Input scalars are 
multiplied. 


polar 


poUrs 


l-real waTeform 

2 Imaginary waveform 


IjnagnJtude wareform 
2.phase waveform 


Lphase units 

^wrapping 

3wdelay 


The block function performs 
rectangular to polar coordinate 
conversion of the Input 


range 




Lwa reform 


Lscalar 


none 


wareforms. 

The Mode function outputs the 
maximum wareform value 
minus the minimum wareform 


rffl 


rflfU 


tifaae domain waveform 


LreaJ wareform 
rfmartmrrwrnrff^ 


■one 


An fit Is performed on the 
Input time domain wareform. 


tine 


sinew 


aone 


L wareform 


LduraUon units 

2.duratlon 

3-ampUtude 

4Jrequency 

&pbase 

&dc oftet 


A suewave Is generated. 


sub 


sub 


1. wa reform 

2. waTeform 


l.wareform 


none 


Waveform 2 Is subtracted from 
waveform I on an dement-by- 
element basis. 


l.wa reform 
2jcalir 


1. wareform 


The scalar Is subtracted from 
each element of the waveform. 


IjcaUr 

2jealar 


Lscalar 


Scalar 2 Is subtracted from 
scalar L 
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Table 2 - Instrument Control block functions 





Rtock Funrltm. 






Otrfpnf* 






ptMlft 


p«5010 


Tektronix PS 5910 
Programmable Power 
Supply 


DOM 


Ian Integer "slgnaF 
Indicating the power 
supply has received 
its parameters and 
hi output it on. 


Lnegatlve volLage 
Ijiegatlve current 
3^odthra fottage 


Thbhkttk fbiKtlffi 
allows GPTB control 
of the power supply. 


fgSOlOA 


ATgSOlO 


Tektronix FG Sol* 
Programmable 
MMHx Function 
Generator 


DOM 


Lab Integer "dgnai* 
indicating the 
lundSon generator 
hat been 

parameterized and 
output It on* 


Lwavefonn type 
l|>c*a>to»peak 
3Jreqoency 
ADC offset 


Tnk block function 
aBowt GHB control 
of a function 
generator. 


frfMOB 


Brs5010 


sameai above 




tame at above 




same at above 


7d20A 


A7d20 


Tektronix 7D20 
Programmable 
Digitizer 


Lan integer "signal" 
indicating that a 
waveform can be 
acquired by the 
digitizer. 


Lwavefonn 


Latarttfme 

3ubtrallon 
4.vonage range 
SJrigger level 
^trigger slope 

Signal maxfanum 
s\aignal in hi hn mn 


This block function 
a] tows GPIB control 
of a digitizer. 


7<G0B 


B7d20 


tame aa above 


nmc as above 


same as above 


same as above 


same *f above 



Table 3 - Miscellaneous block functions 





ftlnrlr Pi m HI a* 


Tnpitfc 


Ontpnfc 




rnmmwh 


amModulator 


amModulator 


Lan Integer "signal" 
Zan Integer "signal" 
3-afl integer "signal" 


1-an Integer "signal" 


none 


This block function Is used for 
synchronization purposes. It only 
creates an output signal when It has 
seen a signal on each of Its 3 Inputs. 
In our examples the Input signals 
cone from 2 function generator block 
functions and 1 power supply block 
function. 


constant 


constant 


none 


Lscalar 


La valoe 


This block function outputs the value 

CTPllri Mttopinmettr. 


fork 


fork 


1. waveform 


Lwavefonn 
2.waveform 


none 


This block function outputs 2 
Identical copies of Its Input 


l.scalar 


Lscalar 

2jfc*l»r 


graph 


waveprint 


Lwavefonn 


none 


none 


This block function sends a waveform 
(on the C-uvSmalHalk pipe) to the 
Smalltalk process to be graphed. 


scalar 


scalar 


1 .scalar 


none 


none 


This block function sends a scalar 
value (on the C-to-Smalltalk pipe) to 
the Smalltalk process to be displayed. 


sink 


sink 


I* SAMPLE 


none 


none 


This block function discards any 
Ipput It recel rs, 
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i » 

Table 4 — Extended Block Editor Menu Functions 



label 

undo 

copy 

paste 

flip 

rotate 
commit 
cancel 
show labels 
build macro 
clear 
repaint 
save 
load 
x execute 



change a label on a block 
undo the last operation 

place a copy of a selected object into a save buffer 
place a copy of the save buffer on the diagram 
reverse a block on the diagram (inputs and outputs move to 
opposite sides of the block) 
. rotate the block by 90 degrees. 

replace the current saved. block diagram with the current diagram 

replace the current block diagram with the saved block diagram 

toggle for displaying labels on the block inputs and outputs. 

build a macro from selected parts on the diagram 

delete the current block diagram and clear the editting window 

repaint the editor pane 

Save the diagram 

Read in a saved block diagram 

Begin execution of the the diagram 



